Cloud docs
Projects
One application, its settings, and what changing them does.
A project is one application. It holds the repository the code comes from, the environments that run it, and the settings that decide what those environments are allowed to be.
#Creating one
You are asked for a name. Nothing else. The project belongs to the team the console is showing, and cannot be moved to another team afterwards. Its machine name is generated for you rather than typed, and it is permanent: it reaches hostnames, paths and backup prefixes. Support level and uptime promise are not asked here, because neither is a decision anybody can make before they have decided what they are building.
Starting a project, and everything on the Configure page, takes the Admin role or above: it is where machines are bought.
The project then needs configuring, and until that is done every link to it goes to the Configure page. This is deliberate: an unconfigured project cannot be built, and a console that let you wander into its environments would be offering pages that can only refuse you.
#Configure
One page, worked down in steps, with the total beside it. Every choice reprices immediately, so the number in the summary is the number you will be billed.
- Plan — dedicated or shared.
- Shape — how many machines, and what each one does.
- Application — what the code is.
- Location — the region, the datacentre in it, and the kind of machine. The region narrows the datacentres to the ones there. The page opens on your billing country where there is a datacentre in it, and on its part of the world otherwise. Prices vary by datacentre — a machine in one genuinely costs more than the same machine in another — so the machines below switch when the datacentre does, rather than one price being shown everywhere and surprising you later.
- Services — what runs beside the site, and the machines it runs on.
- Edge — the origin bandwidth your machines include, more of it if you need it, and a CDN in front. See Plans.
- Add-ons — the staging and development environments beside production, and longer backups.
- Configure project — support, the uptime promise, custom domains and the team.
- Billing period — monthly, quarterly or yearly.
A site joining a shared machine you already have skips what that machine has already decided: its shape, its location, its edge, and its support, uptime and billing period.
Nothing is bought until you build an environment.
#Support and uptime
Both are priced as a share of what your machines cost, so they scale with the size of what is being supported rather than being a flat fee that is wrong at both ends. The configurator quotes the figure before you agree to it.
| Level | Support response | Uptime |
|---|---|---|
| Standard / None | 4-hour best-effort on urgent tickets | 99.5% target |
| Advanced | 75-minute guaranteed on urgent tickets | 99.8% committed |
| Premium | 30-minute guaranteed on urgent tickets | 99.95% committed |
The response times are for urgent tickets — a site that is down. Everything else is answered too; it is the urgent number people are buying.
"Best effort" and "guaranteed" is the whole difference. Standard means we work to four hours and owe you nothing if we miss; the paid levels mean we have agreed to the figure.
The same applies to uptime. Every project runs to 99.5% because that is what the platform runs to — but at Standard it is a target, not something you can claim against. Advanced commits to 99.8% and Premium to 99.95%, and the commitment is the point: a figure you can hold us to, with service credits when it is missed.
In a 30-day month that is about 3 hours 36 minutes of downtime at 99.5%, 1 hour 26 minutes at 99.8%, and 22 minutes at 99.95%.
#Service credits
Where an uptime SLA was bought and the month misses it, a share of that month's invoice comes back. The share is worked out from the Monthly Availability Rate, and it is a percentage of what was invoiced for the resources that missed — a database machine that was down does not refund the CDN that served perfectly alongside it.
It also depends on which tier was bought: Premium costs twice Advanced's surcharge for a tighter figure, so missing it is worth more.
| Monthly availability | Advanced | Premium |
|---|---|---|
| Below the committed figure, at or above 99.0% | 10% | 15% |
| Below 99.0%, at or above 95.0% | 25% | 35% |
| Below 95.0% | 50% | 50% |
The first row runs up to whichever figure you bought — 99.8% on Advanced, 99.95% on Premium. Below 95% the credit is the same either way: a month that bad is the same failure whatever was promised.
Premium support and the Premium uptime SLA are sold on a three-month billing period or longer. A commitment measured in minutes is not something to take on a month at a time.
The Premium uptime SLA needs at least two machines carrying the site. 99.95% is twenty-two minutes a month, which one machine — with nowhere to fail over to — spends on a single update. A site on one machine can buy Advanced; give a service a machine of its own, on the configurator or later on the Upgrade tab, and Premium is on offer. While a project is on Premium, the Upgrade tab will not move production back onto one machine.
The entry line of machines narrows this further. Premium support is not sold on it, and a site on one entry machine can buy no uptime promise at all; one on several can buy Advanced but not Premium.
#Storage
The machine's disk is divided between what fills it: the database, a search index, a queue, public files, private files, and a reserve for mounts. The configurator opens with a sensible split and lets you change each figure: on the machine holding the files the database takes a quarter and the files the rest, and a search index or a queue added beside them takes its share from the files, never from the database. On the flexible and dedicated shapes every machine has a storage box of its own, and a machine carrying two services that fill a disk, say the database beside a search index, halves it between them; either can still be given a disk of its own, and what stays takes the whole machine. Mounts start at nothing: they are the extra directories your application names in vallic.yaml, and whatever you reserve here is shared between them once they are named. A bucket that will not fit, or that you expect to grow, can be given a disk of its own right there, in 10 GB steps to 100 GB and 50 GB steps to 1 TB: one disk for the public files, one for the private files (the mounts go with them), one for search, one for the queue. The database always stays on the machine. Disks are made once the machine exists and are mounted before the first deploy, so nothing ever has to move. The environment's Storage tab shows each bucket against its budget.
Resizing a machine later does not change any of this. The machine's own disk stays the size it was, so the budget and the disks you bought stay as they are; what you moved onto its own disk stays there, and room on the machine is added by buying a disk rather than by a bigger machine.
#Billing period
Monthly by default. A quarter or a year paid ahead is discounted, the same for every plan. It is chosen last on the configurator, because it changes nothing about what is built, only what is paid at once.
A shared plan is always No uptime SLA, and the field cannot be changed. One machine that reboots is a site that is down, and there is nothing to fail over to — selling a promise there would be selling something nothing can keep.
#Changing a project
Before any machine is built, everything is still a choice on the Configure page. Change the plan, the shape, the application, the support level, the uptime promise — nothing has been bought.
Once it is built, the project's configuration page has two cards, each with its own Change:
- Project — the name, the default branch, and the application until something has deployed.
- Commercial terms — support, the uptime promise, the environments beyond production, extra bandwidth and the billing period. The dialog quotes each change before you agree to it. Anything you add is available at once and charged for the rest of the period; anything you reduce stays yours to the end of the period you have paid for and comes off the next invoice. The billing period itself changes at renewal.
| Setting | After it is built |
|---|---|
| Plan | Fixed |
| Shape | Fixed |
| Application | Changeable until the first release is serving, then fixed |
| Support level | Change any time |
| Uptime promise | Change any time |
| Machine sizes | Change any time, up, and down on some kinds |
The ones that lock are not preferences at that point — they are the hardware you are being billed for. Changing a plan or a shape means moving your data to different machines, and changing the application under a running site means a different container running different code. All three are migrations support does for you. See Plans and Shapes.
#Next
Machines covers resizing, Environments covers what actually runs, and Support and Monitoring cover what the support level and uptime promise buy you.