Stopping Development Environments at Night: How a FinOps Lead Cut Non-Production Spend in Half with the Start/Stop Scheduler

The largest waste in most cloud bills is not production. It is the long tail of staging, test, demo and personal environments that run all night and all weekend for people who are asleep. Per-hour billing only saves money if something actually turns the environments off. This post follows a FinOps lead doing that systematically on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, with the Env Start/Stop Scheduler add-on.

The company is a software consultancy we will call Tidewater Digital, with about 60 environments on one PaaS account: 14 production, and 38 that are staging, QA, client demos or developers' own. The Env Start/Stop Scheduler stops and starts an environment on a cron-style schedule in your timezone, preserving data, configuration, domains and IPs.

What stopping an environment actually means

On the platform an environment has three states that matter for billing. Running containers are billed for the cloudlets they consume each hour, RAM and CPU, plus disk and traffic. Stopped containers are billed for disk only: no cloudlets, because nothing is running. Public IPs attached to a stopped environment are retained and still billed hourly, which the lead notes as the one thing stopping does not save. Starting a stopped environment brings every node back with the same data, configuration, internal addresses, domains and IPs, typically in under a minute, longer for large Java applications or clusters.

Nothing is lost by stopping. A developer who left a debugger attached loses the session; the code, the database and the uploaded files are exactly where they were.

Step one: know what you have

The lead uses environment groups to sort the 60 environments: production, staging, qa, demo, personal. Groups also drive access, so the sorting was overdue anyway. The platform's billing history per environment gives each one's monthly cloudlet consumption, and the per-minute statistics show when they are actually used. The picture is what every FinOps lead has seen: the 38 non-production environments consumed 41% of the account's cloudlet-hours, and their usage graphs are flat lines from 19:00 to 08:00 and all weekend.

Step two: schedules per group

The scheduler is installed per environment with one or more cron-style rules and the company's timezone. For the demo group the lead does not schedule starts at all: a stopped demo environment is started from the dashboard by whoever needs it, which takes under a minute, and the scheduler stops it every evening so nobody has to remember. The add-on's optional email on each stop and start goes to a mailbox the FinOps lead reads weekly.

Step three: the exceptions, written down

Two staging environments run overnight integration tests and are excluded, with a note in the group description saying why. One QA environment is used by a client's testers in another timezone and gets a schedule in theirs. The nightly CI pipelines that deploy to staging are moved to 07:45, after the start. And a developer who wants an environment on a Saturday clicks Start; the schedule stops it again that evening. The lead's principle is that the default is off, and on is a deliberate act, not the other way round.

What it saved

Non-production cloudlet-hours fell by 58% in the first full month, from 168 hours a week to a weighted average of about 55 across the four groups plus the exceptions. Because non-production had been 41% of the account, the account's total cloudlet consumption fell by roughly a quarter with no change to production at all. At MassiveGRID's published $0.003372 per cloudlet-hour the saving on Tidewater's account came to several hundred dollars a month before discounts, and the automatic volume discounts the account still qualified for were unaffected because production consumption did not change.

The second-order effect was cultural. When an environment costs nothing to leave stopped, developers stop deleting the ones they might need next month, and stop rebuilding them. The count of personal environments went up by four, and the bill still went down.

What the scheduler does not do

The lead also uses stopping as a lifecycle step. An environment that has not been started in 60 days is a candidate for deletion, which the group listing makes visible at a glance, and the owner is asked before it goes. Three demo environments for prospects who never signed were removed that way in the first quarter, and their disk charges with them.

It does not scale; it stops. For production, the platform's auto-scaling triggers already shed cloudlets when load drops, and stopping production is not the point. It does not stop individual nodes within an environment by default, though per-node scheduling exists for cases like the Jitsi videobridge layer described elsewhere on this blog. And it does not save the public IP's hourly charge, so environments that hold an IP only for a demo domain are moved to the shared load balancer by the lead, where the domain still works and the IP charge disappears.

Frequently Asked Questions

Do scheduled starts and stops appear in the environment's history?

Yes. Each action is a platform operation and is logged like a manual start or stop, and the add-on can email on each. The billing history shows the resulting drop in cloudlet consumption per environment.

What happens if someone is working when the stop fires?

The environment stops gracefully; their unsaved editor state in a web console is lost, their code and data are not. They click Start and continue a minute later. Set the stop time an hour after the working day ends to make this rare, and tell teams the schedule.

Can I apply one schedule to many environments at once?

The add-on is installed per environment, so use the platform's API or CLI to install it across a group with a script, or install it as part of the template you clone new environments from, so every new staging environment inherits the schedule.