Ready for ten times the traffic, containerising a SaaS scale-up with Docker

When growth outruns the way you ship

A SaaS scale-up has a good problem and a hidden one. The good problem is that it worked. Sign-ups are climbing, a few large customers have come on board, and the product is doing what it promised. The hidden problem is that the way the software ships has not grown with it. The deployment that carried the company through its first year is now the thing holding it back.

It usually looks the same. There is one production server, configured by hand over time, that nobody fully understands and nobody dares touch. Deploys are rare because they are scary, so fixes and features queue up and ship in nervous batches late at night. The phrase “works on my machine” gets said often, because each developer’s setup has drifted away from the next one and from production. Then a launch, a campaign or a quiet mention by a larger customer sends a wave of traffic at that single server, and it falls over at exactly the moment the business most needs it up.

None of this means the team did anything wrong. A hand-tuned server is the right call when you are proving an idea and every hour counts. It stops being the right call once real customers depend on the product and growth is the goal. At that point the questions change. Can we ship a fix this afternoon without a ritual. Will the app stay up if traffic doubles next week. If a background job dies halfway through, does the customer lose their export. For an Australian company, there is also the question of where the data lives, because customers increasingly ask for it to stay onshore.

Why containerise with Docker

The fix is to stop treating the running environment as a precious, one-off artefact and start treating it as something you can rebuild from a recipe at any time. That is what containerisation gives you, and Docker is the tool we headline for it.

Docker packages the application together with its exact runtime, libraries and configuration into a container. That container runs the same way on a developer’s laptop, in the build pipeline and in production. The “works on my machine” problem disappears, because every machine is now running the same machine. The thing you tested is the exact thing you ship. Just as important, once the app is a self-contained, stateless container, you can run many identical copies of it at once, which is what makes scaling out possible at all.

A snowflake server, configured by hand and never quite reproducible, gives you none of that. You cannot confidently spin up a second one, so you cannot scale horizontally, and you cannot rebuild it quickly if it fails. Containerisation replaces that fragility with something repeatable.

Around the Docker core sit two supporting pieces. We run the containers on Amazon Web Services, behind a load balancer, in an Australian region so customer data stays onshore. AWS spreads traffic across the running copies and adds or removes copies as load changes, so a spike is met with extra capacity rather than a crash. For the slow, long-running work, those flaky background jobs that used to die on a restart, we use Temporal for durable execution, so a job survives a deploy or a crash and picks up where it left off. Security is built into the pipeline rather than bolted on, with images scanned on build and secrets kept out of the code.

Building it, and where it got hard

The containerising itself is rarely the hard part. The friction lives in the assumptions the old single-server setup quietly made, and one of those almost always bites.

The clearest one was state that lived on the box. The application had been written when there was only ever one server, so it kept things on local disk and in memory as if that server would always be there. Uploaded files sat on the local filesystem. User sessions lived in the app’s own memory. The moment we ran a second copy, customers were thrown back to the login screen at random, because their session was on the other container, and uploaded files vanished depending on which copy answered. The fix was not a cleverer container. It was moving that state out of the app, with files going to object storage and sessions to a shared cache, so any copy could serve any request. Until that was done, running more than one copy made things worse, not better.

The background jobs were the second hurdle. The old setup ran them as fire-and-forget tasks on the same server, so every deploy or restart silently killed whatever was mid-flight. A half-sent batch of emails, a partial data export, a webhook that never fired. Moving those to durable execution meant the work was recorded step by step and resumed after any interruption, which is what made deploys safe to do during the day. We rolled releases out copy by copy behind the load balancer so there was no window where the whole app was down. Getting to routine, daytime, zero-downtime deploys was the goal, and these were the pieces that unlocked it.

What changed

In a representative build, the day-to-day shape of the work changed first. Releases went from a rare, manual, after-hours event to several automated deploys a week, because the pipeline did the work and a bad release could be rolled back in minutes. The team stopped batching changes out of fear and started shipping fixes the day they were ready.

The behaviour under load changed next. With the app running as identical copies behind a load balancer, a traffic surge added capacity automatically and shed it afterwards, so the spikes that used to take the product down became routine. And because long-running jobs now ran on durable execution, a deploy or a restart no longer lost work, so exports, emails and webhooks finished reliably.

These figures are illustrative. They describe the pattern we see when a scale-up containerises rather than a published result for a named company. The shape is the point. The product stops being limited by the way it ships and runs, the team gets its confidence back, and growth becomes something the infrastructure absorbs instead of something it fears.

Where this fits

Containerising a SaaS application is one application of our Cloud Solutions and Integration service, built on Docker, for the technology and software sector. It is a contained, high-return step, because the product already works and the value comes from making it ship and scale reliably rather than rewriting it. If your deploys are rare and a traffic spike worries you, the place to start is to map how the app runs today and find the state and the jobs that still assume a single server.