Shapes

A shape — topology, in the configurator — is how many machines an environment runs on and what each of them does.

#Flexible infrastructure

Your machines, your layout — from one machine up.

Every service starts on the web server. Leave them there and you have one machine running everything: the web server, the application, the database, the cache, with files on local disk and no private network because there is nothing to network to. That is what most sites are, and it is what every staging and development environment is regardless of what production runs.

Move any of them onto a machine of its own, or onto one shared with a couple of others, and you have as many machines as you drew — over a private network the platform creates as soon as there is a second machine to reach. The database on its own for its IO, Solr and the broker sharing a box, a worker keeping the site's CPU free. Each machine is named for what it carries, so the server list reads db, search-queue, worker-cache.

You do not change shape to grow. The same shape covers a site on one machine and a site on six, so spreading out later is a matter of moving a service rather than buying a different arrangement.

Worth doing when the database and the site are competing for the same memory, which usually shows up as the site getting slower under load while neither machine looks busy on its own. It is also the answer when the database has run out of room: the database always stays on the machine, so the way to give it more disk is to give it a machine, or a bigger one.

Varnish can sit on the web server or on a machine of its own, where it shares with nothing. A worker machine never sits on the web server. The Premium uptime SLA needs at least two machines carrying the site — one machine has nowhere to fail over to — so a Flexible site on one machine can buy Advanced. Entry-line machines are allowed here, with less promised on them: on a single entry machine no uptime promise is sold, because there is nowhere for it to fail over to; across several, only the lower one; and Premium support is not sold with an entry machine at all.

On a shared plan there is nothing to draw. The machine belongs to the platform and other sites are on it, so your site runs on that one machine and a worker or an extra — which are second machines — need a dedicated plan. See Plans.

#Dedicated

Every service on a machine of its own — the database, the cache, search, the broker — with nothing shared and nothing to draw, behind a load balancer that is always there. Two web servers at minimum, so the tier survives losing one. The only numbers to set are how many web servers beyond that and how many workers. The database is backed up every four hours, included — on Flexible that is an add-on. Entry-line machines are not offered: the point of this shape is hardware that stays up. From four machines up — the balancer, two web servers and the database — and in practice five, because a Drupal stack also wants a cache.

That minimum is the shape. If what you want is a machine per service and nothing more, Flexible draws exactly that and costs less; what Dedicated sells on top of it is a web tier that keeps answering when a machine goes away, which one web server behind a balancer does not.

Two web servers is a migration, not a checkbox. It is the thing to settle before you buy this shape rather than after. Three things that were local stop being local; the platform handles one of them and the other two are yours:

• Files. Handled for you: one web machine holds the files directory and exports it to the others over the private network, so an upload landing on web-1 is there on web-2. Nothing to do in the application — but it is why the files live on a machine rather than beside each copy of the code, and why a bucket is still the better answer once the uploads are large.
• Sessions. A session stored on local disk logs the visitor out every time the balancer sends them to the other machine. Keep sessions in the database or the cache — Drupal and WordPress already do; Valkey is not required. For an application that cannot move them, Keep each visitor on one web machine in the environment's proxy options pins each visitor to one machine instead, at a price: a visitor loses their session when their machine goes down or restarts, which is the failure the second machine was bought for.
• Scheduled work. Only one machine runs your schedule, so nothing runs twice — but a job that assumes it is on the machine that took the upload, or writes to a local path, will not find what it expects.

Neither of the two left to you is unusual, and every framework we support can do both. But they are work in your application, not a setting here, and worth doing before you buy this shape rather than discovering afterwards.

#A machine for background work

On Flexible and Dedicated you can add a worker machine. It is optional: without one, your schedule and any long-running processes run on the web machine, alongside the site.

That is usually fine, and worth changing when it is not. A nightly import that pins a CPU for twenty minutes is competing with the requests your visitors are making, and the symptom is a slow site rather than a slow import — which is why it is easy to miss.

With a worker machine, the schedule and every process you declared under workers move there. They move rather than split: half the jobs in one place and half in another is an arrangement nobody could reason about.

It is a machine, and it is priced as one. You choose its size like any other, and it appears as its own line on the quote. A worker doing occasional overnight work does not need what your web machine needs.

Without a worker machine, long-running workers are bounded rather than refused: one declared worker per machine that can run one — each worker machine where you have them, each web machine otherwise. A process that never exits competes with the site for the CPU that answers requests, and one apiece is the most that leaves the site able to answer. A deploy that declares more than there is room for says so, and the answer is a worker machine, another web server, or folding the work into a worker you already have — see vallic.yaml.

#Changing shape

You cannot move an existing project between Flexible and Dedicated, or between plans. Moving from one machine to several is a move of your data between machines, and doing it silently under a running site is how data gets lost. Adding capacity within a shape — bigger machines, more disk — is always available.

Within Flexible there is one exception: the project's Upgrade tab can give the database, cache, search or queue a machine of its own after the site is built, and bring cache, search or queue back. It shows what will move and what it costs in downtime before anything happens — see Upgrades.

Within Dedicated, the same tab changes how many web servers and workers there are. Every web server is the same size — traffic is shared between them evenly, so a smaller one would set the pace for all of them — and a new one is built at the size of the others. It is sent your live code before it takes any traffic, so adding one never serves errors while it catches up. Fewer takes away the highest-numbered machines, after the load balancer has stopped sending them requests. The subscription follows the machines either way. To change their size, resize any one of them on the machines page: the others in the role move with it, one at a time.

#Next

Software stacks covers what actually runs on these machines.