The Upgrade tab — giving the database, cache or search a machine of its own after a site is built, and what each move costs in downtime.
A site usually starts with everything on one machine. When one service starts competing with the rest — a search index eating the memory PHP wants, a database that needs the disk to itself — it can be moved onto a machine of its own without rebuilding the environment. That is the project's Upgrade tab.
This is the one way a built environment's layout changes. It moves services between machines; it does not change a shape in any other way.
The tab shows every environment of the project, its machines, and what runs on each. For each service that can move there is a choice:
You are shown a summary of what will move before anything happens. The new machine is built first; the service follows.
| Service | Onto its own machine | Back again |
|---|---|---|
| Cache, search, queue | Yes | Yes — the emptied machine is removed |
| The database | Only while the environment is still one machine | No |
| Varnish | No | — |
| The web tier | No | — |
Move the database first. It is only offered while everything is still on a single machine. Once the cache or search has moved off, the database option disappears, so if you want both, do the database before anything else.
Varnish is not offered because it becomes the front door: moving it would move where your DNS points, before the machine it points at existed.
Each service gets its own machine. Two moved services cannot share one.
On the Premium uptime SLA, production keeps at least two machines. Premium is only sold on two, so a move that would bring production back onto one is refused. Move the project to Advanced in its commercial terms first; that takes effect at the next period, and the move is possible from then.
The tab does not add web machines or workers, and does not change the plan.
Cache, search or queue: the service stops while it moves, and its data is not copied — it is rebuilt. A cache refills on its own. A search index has to be re-indexed by your application. Do not count on jobs still sitting in a queue surviving the move — let it drain first.
The database: your site shows the offline page for the whole copy. The new machine takes a dump of the database from the old one and loads it; nothing can safely write to the database while that happens. A small database is minutes; a large one can be the better part of an hour. Plan it for a quiet time.
The site's address does not change. Nothing you have in DNS needs editing.
Nothing, if it reads its connection details from the environment. The
platform rewrites DB_HOST, REDIS_HOST, SOLR_HOST and the rest to point at
the new machine, over the private network. The credentials and the database name
stay the same.
An application that has localhost or 127.0.0.1 written into its
configuration will lose its database the moment it moves. Check before you
start — see Variables and your framework's page.
When the database moves, the copy on the web machine is kept for 72 hours, and then removed. It is not served from — it is there in case something about the move needs looking at. Pointing the site back at it is a support request, not a button.
You can remove it sooner from the Storage tab, and if you set the disk split yourself, that tab is also where to reclaim the room it leaves.
A new machine is added to the project's subscription at the price shown beside its size, from when it is built. A machine removed by moving a service back comes off it. See Billing for how part-months are charged.
The Admin role, once the project has been built. See Teams.
Progress is under Activity.