Cloud and DevOps, from a team that operates its own platform.
Deploys, rollbacks and 3am pages are not somebody else’s department here: we built and run DeployCloud, our own container platform, and every product in our catalogue ships on it. Health-gated releases, preview environments per branch, autoscaling, metrics, alerts, log drains, scheduled backups and one-click restores are things we operate daily, not services we resell.
For a client that usually means one of three jobs: making releases boring, making the system observable enough that failures are noticed by monitoring rather than by customers, or making a restore something you have actually rehearsed.
What the engagement actually contains.
We built and run our own PaaS, so deploys, rollbacks and 3am pages are not somebody else’s department here.
- 01
Zero-downtime releases with health-gated cutover
A new release takes traffic only after it answers its health check; if it never does, the previous one keeps serving and nobody gets paged.
- 02
A preview environment per branch
Every branch gets its own URL, so review means clicking the change rather than imagining it from a diff.
- 03
Autoscaling and capacity that matches the season
Scaling driven by real metrics with cooldowns, sized for Black Friday without paying for Black Friday in March.
- 04
Metrics, alerts and log drains
CPU, memory, request rate, status mix and latency, with thresholds that page a human and logs forwarded wherever you already look.
- 05
Backups, restores and disaster drills
Scheduled backups with retention, and a restore that has been practised. An untested backup is a hope, not a plan.
Where we have already done this.
Our own catalogue, not a case study written for this page. Every name below is public software you can open right now.
DeployCloud
Our own PaaS: git URL in, running HTTPS app out — builds, health-checked releases, rollbacks, add-ons, autoscaling and backups. This page is served by it.
Jentry
The observability product we built and operate, which is where the monitoring opinions come from.
Ten products, one platform
Everything in our catalogue runs on the same infrastructure we would set up for you.
What people ask before starting one of these.
Do we have to move to your platform?
No. Most of this work happens on your infrastructure — your cloud account, your cluster, your bill. DeployCloud is where our opinions came from, and it is an option when you would rather not own the platform layer at all, but it is never the price of the engagement.
Can you help us survive Black Friday?
Yes, and the useful version of that work happens in September: load-test the paths that actually break, fix the ones that do, set autoscaling limits and alert thresholds, and rehearse the rollback. In November the only good move left is a freeze.
What does "observable enough" mean in practice?
That when something breaks, the alert arrives before the customer email, and the logs and metrics answer what happened without a redeploy to add logging. That is a small amount of work done early and an expensive one done during an incident.
More general questions — cost, ownership, what happens after launch — are answered on the home page FAQ.
Have a cloud, devops & scale project?
Send the spec and an engineer answers within 48 hours — how we would build it, the rules that apply, and a price. The first working build follows days later, not quarters.
- A costed answer within 48 hours
- A working build you can click in days, not quarters
- Fixed price or T&M, quoted before we start
- Server, domain, SSL and monitoring handled — or shipped into your cloud
- You own the repo, the Partner account and the infrastructure
Prefer the company site? devcloudsoftware.com