Start, stop and schedule your servers
You can switch your project's servers off when nobody needs them, and on again when they do, from the Dashboard. You can also set this to happen on a schedule, such as office hours or weekends, together with resizes at set times.
Stopping and starting a server
Each server The Deployer created for your project has its own tile in the server card on the Dashboard.
- Click Stop server on the server's tile.
- Read what stopping means on your cloud, then tick I understand my app will be offline.
- Click Stop in the dialog.
To bring it back, click Start server on the tile. When servers are stopped, a banner at the top of the card also offers Start for one server or Start all servers for several.
Each start or stop runs as a small deployment, so you can follow it in the live logs. A start is checked like any deployment: The Deployer waits for your app to answer before it calls the start done. On AWS, Google Cloud and Azure the server's public address can change when it starts, so The Deployer updates your domain's DNS records to the new address. Starting usually takes 1 to 3 minutes.
When you have several servers, data servers (such as a database server) start before the app and stop after it.
Starting or stopping never counts against your plan's limits. A server your cloud provider stopped over an unpaid bill can always be started here once you have settled the bill. Until then the provider refuses the start.
Stopping the managed database
On AWS, Google Cloud and Azure you can also stop the project's managed database. Use Stop now or Start now beside the database in the Scheduled operations card. Your data is kept, but your app can't reach the database while it is stopped.
- AWS starts a stopped database again by itself after 7 days, and Azure after 30.
- DigitalOcean managed databases can't be stopped. They run until they are deleted.
- No provider lets you stop a managed cache. You can only resize it.
What a stop pauses
While you have stopped every server of a project:
- Uptime alerts pause. You don't get "your app is down" emails for an app you switched off on purpose. This also applies while the managed database is stopped.
- Push-to-deploy pauses. A push doesn't try to deploy to servers that are off.
- Automatic retries pause. A failed deployment isn't retried while the servers are stopped.
All of this resumes as soon as the servers are running again, whether you start them here or in your cloud provider's console.
What still bills while stopped
Your cloud provider bills you directly, and stopping does not stop every charge:
- AWS and Google Cloud. Compute billing stops while the server is off. Its disk is still billed.
- Azure. The server is deallocated, so compute billing stops. Its disk is still billed, and its public address is kept.
- DigitalOcean. A powered-off droplet is billed at the full rate. The only way to stop paying is to delete it.
- Hostinger. A stopped VPS is billed for the rest of its paid term.
- Managed databases. On Google Cloud, storage is still billed while the database is stopped.
The Cost card follows the hours a server or database was off. See Costs & billing.
Scheduling a start, stop or resize
The Scheduled operations card on the Dashboard lets you plan these ahead. You can schedule:
- Servers The Deployer created: start, stop and resize.
- The managed database: resize, and start or stop on AWS, Google Cloud and Azure.
- The managed cache: resize.
Projects with no servers (static sites, serverless containers) have nothing to schedule, so the card doesn't show.
To add one:
- Click New schedule on the Scheduled operations card, or Schedule on a server's tile.
- Pick the Server or service and the Operation.
- For a resize, pick the New size.
- Under Repeat, choose One time, Daily or Weekly. Set the Date and time, or the Time of day and, for weekly, the Days.
- Check the Time zone.
- Click Schedule.
The card has three tabs: Schedules (with Pause, Resume and Delete on each), Next 7 days, and Runs, where you can search past runs and filter them by outcome.
One operation at a time
Operations on one project never overlap. Each one runs as a normal deployment. If anything is still running when an operation is due, including a deployment you started yourself, the operation waits and starts as soon as the earlier one has finished. Due operations run in the order they were scheduled for.
For example, a stop at 18:30 that takes until 18:40 pushes an 18:35 start back to 18:40. When you create a schedule that is likely to wait like this, The Deployer tells you.
The plan for each operation is made when it runs, so it matches your project as it is then. If an operation no longer makes sense (the server is gone, or the size is already applied), it is skipped and the skip is shown in Runs. An operation that is more than 24 hours late is skipped too, rather than run at a surprising time.
An AI coding agent connected through The Deployer's MCP server can do this for you too: see Use The Deployer from your AI coding tool.
Common problems
- "Two operations on the same server or service can't run in the same minute." You picked a time that collides with another schedule on the same target, now or on a later repeat. Pick another time.
- Resuming a paused schedule fails. Resuming would collide with another schedule, or a one-time operation's time has passed. Delete it and schedule a new one.
- No Stop or Start button. Starting and stopping needs the Start and stop permission. Scheduling needs Start and stop or Scaling. See Working with your team.
- The server runs other projects. Stopping it stops every project on it, so you are asked to confirm, and only someone who can manage the server can do it. See Servers.
- Your own server shows Restart instead. A server you connected yourself has Restart server, which reboots it from inside, because nothing could switch it back on after a stop. A Hostinger VPS in a connected Hostinger account is the exception: it has Stop and Start.
- Start fails after a billing problem. Settle the bill with your cloud provider first, then click Start again.