The Deployer documentation
After you're live: the Dashboard

Scaling: resize servers, databases, caches and containers

When your app needs more power, or less, you can change what it runs on from the Dashboard. You don't have to redeploy by hand. Each change runs as a small deployment with live logs, and The Deployer checks that your app answers again before it calls the change done.

What you can scale

The Scaling card on your project's Dashboard lists everything this project can scale right now, with its current size and an estimated monthly price. The card appears once the project has been deployed. What it lists depends on the architecture you chose:

WhatWhat you can changeDowntime
A serverIts size (machine type)Usually 1 to 3 minutes. None for an app server behind a load balancer when another app server keeps serving.
A managed databaseIts size, and the standby copy (high availability)A brief connection blip, usually under a minute. Your data is untouched.
A managed cacheIts sizeA brief connection blip, usually under a minute.
Serverless containersThe size of each instance, and how many instances stay running (up to 10)None. New instances take over only when they are healthy.
Kubernetes cluster nodesHow many nodes the cluster keeps (up to 10)None. Nodes are added or drained gradually.

This works the same on DigitalOcean, AWS, Google Cloud and Azure. A few things are not offered:

  • Servers The Deployer didn't create. If you brought an existing server into a project, it stays yours to resize.
  • Static sites on a CDN. They have no size to change.
  • GKE Autopilot clusters. Google adds and removes nodes for you, so the nodes row is greyed out.
  • A Kubernetes cluster can't go below what your services need. The dialog says how many servers they need to fit.

Changing a size

  1. Open your project's Dashboard and find the Scaling card.
  2. Click Change next to what you want to scale. For a server, you can also click Resize on its tile in the server card. Resize shows only while the server is running.
  3. Pick the new size:
    • For a server, you see every machine type your cloud offers in the server's region, with vCPUs, memory and a monthly price. Use the search box (for example "4 vCPU" or "16 GB") or the kind filters to narrow the list.
    • For a database, cache or containers, pick one of the sizes listed.
  4. For containers or cluster nodes, use + and − to set the count.
  5. Read the cost line. It shows the estimated monthly price now and after the change.
  6. If the change takes your app offline for a moment, tick I understand there will be a brief interruption.
  7. Click Apply change.

You are taken to the live logs straight away, just like Pull & Restart.

How a resize runs

A resize is a short deployment with its own steps:

  • A server is powered off, changed to the new size and started again. On AWS, Google Cloud and Azure the server's public address can change when it starts again, so The Deployer updates your domain's DNS records to the new address for you. DigitalOcean keeps the address.
  • A database or cache is changed in place by your cloud provider.
  • Containers roll out new instances next to the old ones. The old ones are removed only once the new ones are healthy.
  • Cluster nodes are added or removed gradually while your services keep serving.

At the end, The Deployer waits for your app to answer and checks every live address from outside. A resize is not marked as succeeded while your app is unreachable. After a successful change, the Dashboard shows the new size and the new price.

A standby copy of your database

For a managed database, the dialog also has a Standby copy (high availability) switch. A standby is a second copy of the database that takes over by itself if the first fails.

  • It is off unless you turn it on.
  • You pay for both copies. The dialog shows roughly how much more it costs at the size you picked.
  • Before you apply, the dialog says what turning it on or off does to your running database on your cloud.
  • On Azure, the Small and Medium sizes can't have a standby. Choose Large or bigger first.
  • A resize alone never adds or removes the standby. Only the switch does.

See Costs & billing for what a standby copy covers, and what it does not.

What it costs

The prices in the dialog are estimates, so you can compare sizes before you choose. Your cloud provider bills you directly for whatever size you run, at its own prices. If a size would cost more than the safety limit on monthly spend, the dialog shows the price and asks you to confirm it: click Confirm this price and apply.

A capacity change counts as a deployment toward your plan's daily limit.

You can also run a resize at a set time, for example every night or every weekend. See Start, stop and schedule your servers.

An AI coding agent connected through The Deployer's MCP server can do this for you too, and tells you the new price first: see Use The Deployer from your AI coding tool.

Common problems

  • The Scaling card says nothing can be scaled yet. Options appear once your app is live and its architecture has something with a size.
  • No Change or Resize button. Resizing needs the Scaling permission on this project. Ask the workspace owner. See Working with your team.
  • The server runs other projects too. Resizing a shared server affects every project on it, so only someone who can manage that server can resize it. See Servers.
  • "The database is stopped, so it can't be changed." Start the database first, then resize it.
  • Another deployment is running. Wait for it to finish, then apply the change.
  • The size isn't offered in this region. Pick another size from the list. The list shows only what your cloud offers where the server runs.