Zero-Downtime Deployments in Romania

What a release without interruption looks like

We bring up the new environment beside the one serving traffic, start it with the same configuration and run smoke tests against it. If they pass, we move traffic at the ingress or load balancer, draining open connections so nobody is left with a request cut in half. The old environment stays running until the metrics confirm the new version behaves. If they do not, we switch back at once, with no rebuild and no reinstall.

• Smoke tests run automatically before the switch
• Connection and session draining while traffic moves
• Canary releases by traffic percentage, with thresholds on error rate and latency
• Feature flags for the riskiest changes

Best practices we apply on every release

Zero downtime does not come from the tool. It comes from the discipline applied at each step. The list below is exactly what we check before, during and after the traffic switch, and it stays written in the release procedure you receive at handover. We follow it even when a release looks trivial, because big incidents almost always come from deployments somebody judged too small to deserve checks.

• Migrations that break compatibility never ship together with the code
• Automated smoke tests are mandatory before traffic moves
• Rollback is one command, rehearsed rather than only documented
• The old environment stays live until the metrics confirm the new version
• Release windows chosen around the working hours of your Romanian customers

Database migrations, the hard part

Code switches in seconds, a schema does not. So we split every change into two phases. First we expand: add columns or tables that both versions understand. Once the new version is stable, we contract and remove what is no longer used. Between the two phases the old and new application can run side by side. That way a rollback never meets a schema the previous version no longer recognises.

• Expand phase: add, never delete or rename
• Dual writes or default values for compatibility
• Contract phase only after the new version is confirmed

What your included hours cover

Setting up the release procedure comes out of the monthly hours in your plan: 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, 10 h on GPU servers. Request it in the client panel under DevOps Services, usually ahead of an important launch. The first setup normally takes most of the allowance; after that every release is routine for your team. Hours above the quota are accepted and billed separately.

How we work

1. Request it in the panel

   Describe how you release today, what breaks most often and when your next major version is due, then propose a deadline.

2. We scope the work

   We pick blue-green, canary or rolling updates to fit your architecture and agree the thresholds that stop a release automatically.

3. We build it and rehearse a rollback

   We configure the environments, the smoke tests and the switch, then run a trial release and a real rollback, so the procedure is proven.

4. Handover with documentation

   You receive the release procedure, the rollback command, the stop thresholds and the rules for schema migrations, kept in your own repository.

Use cases

Technology stack

• Kubernetes
• Argo Rollouts
• Flagger
• Traefik
• NGINX
• GitHub Actions
• Flyway
• Prometheus
• Unleash

Frequently asked questions

• What is blue-green deployment?

  Two identical environments: one serves traffic while the other receives the new version. You test on the idle one, then move all traffic across. The old one stays up as a safety net, so going back is a switch rather than a reinstall.

• When should I use canary, blue-green or rolling updates?

  Blue-green is simpler and suits a clean switch with fast rollback. Canary is better when you want to watch real traffic before exposing everyone, but it needs trustworthy metrics and thresholds agreed in advance. Rolling updates are the baseline on Kubernetes.

• How do I handle database migrations in a blue-green release?

  In two phases. First extend the schema with elements both versions understand, release the code and confirm it is stable, then contract and remove what is unused. The fixed rule: no migration that breaks compatibility ships together with the code.

• Can I do blue-green on a VPS, or do I need Kubernetes?

  A VPS is enough. With Docker Compose and Traefik or NGINX we run two stacks side by side and flip the upstream. Kubernetes adds finer tooling, such as Argo Rollouts or Flagger, but it is not required for a clean zero-downtime release.

• Do I need double the resources for two environments?

  Only temporarily, during the release. On Kubernetes the extra environment exists for a few minutes and disappears after the switch. On simpler setups we hold a calculated capacity reserve, so you do not pay all month for an environment you rarely use.

• How do I roll back instantly if a release fails?

  We keep the images and manifests of earlier versions, and moving traffic is a route change, not a rebuild. We rehearse the command with you at delivery and add it to the procedure, including what to do if a schema migration ran in the meantime.