Elastic runtimes

Elastic runtimes are available on every tier. Each instance gets a machine of its own, so the licensed per-runtime instance cap is also how many machines can run at once — see how machines count below.

What is still narrow

Elastic runtimes arrived in 1.4, with the Google Compute Engine provider: GET /api/provisioners lists gcp. The machines can be listed, reconciled against the cloud account and reclaimed when one leaks; an instance's containers report what they are costing; the runtime form, the machine profiles, the machines view, the environment's profile picker and the machine on an instance's card are in the web interface, and the CLI lists a runtime's machines. What is still narrow:

• No usage figures for an elastic runtime itself — no CPU, memory or disk bars, and no fadebox_runtime_* Prometheus series. The per-container figures are read off each machine; the runtime-level reading is how many of its machines answered.
• No provider beyond Google Compute Engine.

A runtime is normally a Docker host somebody already built: an admin installs Docker on a machine, secures the daemon, pastes three PEM blocks, and from then on that host costs the same whether it runs twenty instances or none. Instances expire on a clock; the host under them never does.

An elastic runtime turns the host into part of the instance. The admin defines the runtime once — a cloud account, a network, a set of machine sizes — and Fadebox creates one virtual machine per instance, on demand:

• Deploying an instance creates its machine, boots it, brings up a Docker daemon behind mutual TLS, and then deploys onto it exactly as it would onto any other runtime.
• Stopping the instance switches the machine off and keeps its disk, so the volumes and the image cache survive and the bill drops to the price of a stopped disk.
• Deleting the instance destroys the machine, disk included.

Two things come out of that. Cost follows the instance: an environment nobody has opened for a week is a stopped disk, not a share of a host that is always on. And isolation is a kernel boundary: a template author who is effectively root on the host is root on a machine nobody else is on, which is a much smaller sentence than the one a shared runtime has to make — see who may deploy where.

Three things to weigh first

Before the shape of the feature, the three facts most likely to decide whether it suits you:

• A cold start is minutes, not seconds. Booting a machine and pulling a multi-gigabyte stack into an empty image cache is the honest cost of an instance's first deploy. There is no pool of warm machines waiting to be claimed, and the only thing v1 does about it is keep the disk when you stop — so the second deploy of the same instance starts a machine that already has the images. Bake what you can into the machine image, and if a pipeline waits on a deploy, size its timeout for the cold case.

• While a machine boots, read access to the cloud project is access to its daemon. Fadebox configures each machine through the provider's own instance metadata, and that document carries a certificate authority and its private key — on Google Cloud, anybody holding compute.instances.get can read it. That key is single-use: it vouches for exactly one machine, and whoever has it can mint a certificate that machine's Docker daemon accepts, which is root on that machine and everything its instance holds. It reaches nothing else — not another machine, not another runtime, not Fadebox itself — because every machine gets a CA of its own and nothing else in the installation trusts it. Once the machine is ready, Fadebox removes the document from the metadata, so the exposure is the minute or two from create to ready — and any machine whose removal keeps failing, which the server log names. Reading a project is a much weaker right than logging into a machine, so it is worth naming before you decide who gets it.

• It is on every tier, and machines have no cap of their own: one instance is one machine, so the per-runtime instance cap bounds them. Running instances are what count; a stopped machine keeps its disk and does not. See how machines count.

How it differs from a static runtime

	Static	Elastic
What you point it at	One Docker daemon (tcp:// or a socket)	A provider account — a cloud project, a network
Hosts	One, built and kept by you	One per instance, created and destroyed by Fadebox
Sizing	Whatever the host has	A machine profile named on the environment
Instance URLs	The runtime's own ingress domain	The front runtime's domain, scheme and port
First deploy	Seconds	Minutes — a machine has to boot and pull
Cost when idle	The host, always	A stopped disk per stopped instance
Cost when empty	The host, always	Nothing

Everything above the host is unchanged. Templates, environments, overrides, ingress hostnames, expiry, reset, the deploy history and the CLI all behave as they do on a static runtime, because what a provider does ends at here is a reachable Docker daemon and the deploy engine starts there.

A runtime's placement is fixed when it is created. A static runtime never becomes elastic, and an elastic one never changes its provider — every machine under it is a handle only the provider that made it can read. Another provider is another runtime.

The instance and its machine

You do this to the instance	This happens to the machine
First deploy	Created, booted, bootstrapped; the deploy follows by itself once the daemon answers
Redeploy	Nothing — the machine is already there and its image cache is warm
Stop	Switched off, disk kept: the instance's volumes and its pulled images survive
Deploy after a stop	The same machine is started again, on whatever address it comes back with
A deploy that fails	Switched off, disk kept, as by a stop. The instance is in ERROR with the reason, and its next deploy starts the same machine again
Reset	Kept. Reset removes the instance's volumes as it always has; the machine and its image cache stay, which is what makes a repeated reset fast
Expiry	Stopped, exactly as a manual stop — expiry stops, it never deletes
Stopped longer than the runtime's retention	Destroyed. The instance stays STOPPED; its next deploy starts from a fresh, empty machine
Move to another runtime	Destroyed. A machine belongs to the account that made it, and a move never carried volumes anyway
Delete	Destroyed, disk included

The only operations that destroy a disk holding your data are therefore delete, move, and the admin's stopped-machine retention. A failure never does — see when something goes wrong.

Fadebox reaches each machine the same way it reaches a remote daemon: tcp://<address>:2376 with mutual TLS. Nothing runs on the machine on Fadebox's behalf but Docker itself — there is no agent, and a machine never dials back.

PROVISIONING

A machine takes minutes, and Fadebox can restart in the middle of one. So an instance on an elastic runtime gets one more status than the lifecycle elsewhere:

DRAFT/STOPPED/ERROR/RUNNING ──► PROVISIONING ──machine ready──► STARTING ──► RUNNING
                                     │ (stop = cancel)             ▲
                                     └──────────► STOPPED          │
RUNNING/ERROR, machine up ─────────────────────────────────────────┘

PROVISIONING means the deploy has been accepted and is waiting for a host to exist. Nothing has been deployed yet, so there are no containers and no container logs — what there is to read is the machine log.

A redeploy onto a machine that is already up skips it. Redeploying or resetting a RUNNING instance — or one in ERROR whose machine is still running and nobody has asked to stop — goes straight to STARTING, exactly as on a static runtime: the host is there, so there is nothing to wait for. A stop right after it is an ordinary stop, which removes the containers and keeps their logs. PROVISIONING is for a machine that has to be made, started, or waited for.

What you can rely on while an instance is PROVISIONING:

• The deploy follows by itself. Once the machine's daemon answers, the instance moves to STARTING and the deploy runs with the values it would have used anyway, attributed to whoever asked for it — minutes earlier, possibly on a different Fadebox process.
• It survives a restart of Fadebox. Unlike STARTING, no worker is parked on it; the whole state is the machine's own row, which is the point.
• Stopping cancels it. A stop from PROVISIONING lands the instance on STOPPED at once — there are no containers to tear down — and the machine is given up in the background. fadebox instance stop and the UI's Stop both do this.
• Deleting is refused while an instance is provisioning, as it is from any busy status: a machine may already be billing. Stop it first, which is instant, and then delete.
• It is busy. A second deploy is refused, and the instance holds a slot against the licensed per-runtime instance cap — which on a cloud account doubles as a cap on how many machines can be running at once.

This is where the cold start is spent. fadebox instance up --wait waits through PROVISIONING like any other non-terminal status, so a pipeline needs no new handling for it — only a timeout sized for a machine that has to boot.

Watching a machine come up

Those minutes are not silent. Fadebox writes a short machine log as it makes, starts and stops an instance's machine — one line per step, said once, however many times it checks on the machine in between.

On the card, the latest line sits under Provisioning machine…, so a deploy that is waiting for a daemon does not read as one that has stalled. In the status panel (Live status & logs), the log pane's service list gets an entry named machine, with the whole log, oldest first. While the instance is PROVISIONING it is the only entry; once the containers are up it sits beside them. The entry is also offered on an instance in ERROR, where the machine may be gone and its last lines are the explanation. A Compose service that is itself called machine keeps that name and its own logs, and the entry is not offered.

A first boot reads like this:

Machine requested on runtime cloud, profile standard-4
Asking gcp for a machine
gcp created the machine
Waiting for the machine to start: STAGING
The machine is running; waiting for its Docker daemon
The daemon answered; starting the ingress router
Machine ready
Deploying

Line	What is happening
Machine requested on runtime …, profile …	The deploy was accepted and a machine was claimed for it. Every deploy's story starts here.
Asking gcp for a machine · gcp created the machine	The provider was called, and accepted. From the second line on, the machine exists and is billing.
Waiting for the machine to start	The provider says the machine is not running yet. After the colon comes the provider's own word for where the boot has got to — on Compute Engine, PROVISIONING or STAGING. A provider that says nothing leaves the colon out.
The machine is running; waiting for its Docker daemon	It has booted and has an address, and its daemon is not answering yet. This is where cloud-init is doing its work.
The daemon answered; starting the ingress router	The machine is reachable; Fadebox is starting the router on it. The ingress router is not up yet; trying again follows if the first try fails, once.
Machine ready · Deploying	The machine is a host, and the deploy itself starts — the instance moves to STARTING. After a reset the last line is Resetting, then deploying.

When something goes wrong, the last line is the reason — the same sentence the instance's error carries, such as the provider's quota message. A stop adds Asking gcp to stop the machine and Machine stopped; its disk is kept; a deploy from there goes on with Asking gcp to start the machine and then the same waiting, daemon, router and ready lines as a first boot. A stop before anything was made reads Cancelled before a machine was made, and a disk that retention ended reads The machine's disk was given up under the runtime's retention.

The log belongs to the instance, not to the machine, so it outlives a machine that was given up and goes only when the instance is deleted. Every project viewer can read it — the card's line, and the whole log over the API; the machine entry is one more entry in the log pane, so it shows wherever that pane does. It is written for that audience: it never carries the machine's name, its address, or anything about the cloud account — waiting for its Docker daemon, never the IP. The provider's name and the profile's are the ones the card already shows.

Two more ways to read it:

• fadebox instance up --wait (and deploy --wait, reset --wait) prints the same lines on stderr, as machine: <line>, while the instance is PROVISIONING — so a CI job log shows the machine staging instead of three quiet minutes. It starts at this deploy's own Machine requested line, not at an earlier boot's, and stdout still carries only the result. See the deploy loop.
• Over the API, GET /api/projects/{project}/environments/{env}/instances/{slug}/machine/log answers text/plain, one <instant> <line> per line, oldest first; tail (default 200, at most 5000) keeps the most recent lines. An instance with no lines — one on a static runtime — answers 200 with an empty body, and unlike the container logs it never answers machine_not_ready. The instance's machine block carries the latest line as progress, which is what the card shows.

Machine profiles are the sizing and the spend control

An elastic runtime does not ask a deployer how big a machine should be. The admin defines named machine profiles on the runtime — small, large, gpu — each a set of the provider's own parameters: the machine type, the image, the disk size, whether it is a spot machine. One of them is the default, and a runtime that has any profiles always has a default.

An environment names one profile, or names none and gets the runtime's default. That is the whole sizing model in v1:

• The admin decides what exists, so a deployer picks among sizes somebody has priced rather than typing a machine type into a form. There is no per-instance override.
• A profile is provider-native. e2-standard-4 is a thing you can say, because the parameters are the provider's own keys and not an invented cpus/memory pair that could never express spot, a disk type or an image family.
• An environment that names a profile the runtime does not define is refused at deploy, with the list of profiles that runtime does define. Silently deploying a JVM stack onto the default small machine is the worse failure.
• A profile name travels with the environment, not with a runtime row. An environment that moves between runtimes arrives already sized, and a profile deleted from a runtime does not rewrite any environment — the next deploy onto that runtime of an environment that names it is simply refused.
• The default sizes only a machine being created. An environment that names no profile takes the runtime's current default on the deploy that creates its instance's machine. Every later deploy or reset wakes the machine the instance already has, at the size it was made with — whatever the default has become since, and even if that profile has been deleted. Changing the default changes the size of new machines and breaks no instance that exists.

Machines already created keep the profile name they were sized by, so a machine's history still says how it was built after the profile is gone.

Who sees what. The names are the environment's business, so anyone who may see a runtime sees the sizes it offers and which one is the default. The parameters behind a name — the machine types, images, disks and subnets of the cloud account — stay with the admin who priced them.

An editor picks one with the environment's Machine profile picker, or sets it over the API.

Where instance URLs come from

An elastic runtime has no ingress settings of its own, and a machine has no DNS name, no certificate and no public address. Giving each machine those was refused: it needs a DNS provider on every platform, and a certificate per machine runs into issuance limits at exactly the usage this feature is for.

Instead, all traffic enters through the front — a static runtime whose managed ingress stack already holds the wildcard DNS record and the certificate. Every elastic runtime names one, and instance hostnames are built the usual way from the front's ingress domain, scheme and port. On the machine, an ingress router does the last hop:

browser ──HTTPS──► front ──mutual TLS──► ingress router ──► container
                (TLS, wildcard,          (on the machine,     (the service
                 sign-in check,           port 443, admits     the hostname
                 public DNS)              the front only)      names)

The front asks Fadebox every few seconds where each hostname currently lives and forwards to the machine behind it. The ingress router on that machine picks the container the hostname names, exactly as the ingress on a static runtime does. Consequences worth knowing before you design around it:

• Fadebox starts the router itself, during the machine's boot — between the machine's Docker daemon answering and the machine being marked ready. A machine is ready only once its router is current and running, on a first boot and after a restart alike, so a deploy is never handed a machine that cannot serve what it is about to start. The router is two small containers, and an image that does not already carry them pays two registry pulls on every cold start; baking them in is part of the image contract.
• All traffic hairpins through the front host. The front and Fadebox must both be able to route to the machine network.
• No machine needs a public address, and none gets one by default. The machine's port is open to the front alone, and it accepts only the front's client certificate: a request that goes around the front fails at the handshake.
• A machine never calls Fadebox. Fadebox dials the machine's daemon and the front dials its router; nothing on the machine needs a route back, so a control plane behind a firewall that only lets connections out still works.
• Host-published ports are not published to the world. A service that publishes a port without going through ingress answers on the machine's own address, reachable only from inside that network.
• A hostname is still unique across the whole installation. Two live instances can no more share a name across a static and an elastic runtime than they can on one host.

Whether an instance's URLs require a sign-in is unchanged and is still the instance's own setting. The check is enforced at the front, exactly as on a static runtime, and nothing reaches a machine without passing the front, because the router admits only the front's certificate. The router believes forwarded headers from the front's range and from nowhere else, so the container still learns the visitor's address and scheme, and anything a caller elsewhere on the machine network claims about them is discarded.

When something goes wrong

The instance says why, in the provider's own words. A quota that ran out, a zone with no capacity left, a rejected credential — the sentence the platform gave is what lands on the instance as its last error and what the deploy history shows, because "quota CPUS exceeded in europe-west3" is the sentence that tells an admin what to do.

• Coming up has a time limit per step. Asking the provider for a machine, booting it, and bringing one back after a stop are each given fifteen minutes by default. A machine that is slow at every step but keeps finishing them is not failed; what the limit ends is a step that stopped moving, and the reason names the step — the machine reported no address, the Docker daemon on 10.0.0.7 never answered over mutual TLS.
• A machine whose ingress router will not start never becomes ready. The router goes on after the daemon answers, so a machine that gets that far but cannot pull the router's images is retried on every sweep, with the reason kept on the machine; when the step runs out of time the deploy fails naming the router and what stopped it.
• A machine that never became a host is destroyed. If it failed while it was being created or booted, nothing of yours was ever on it, and leaving it half-made would leave it billing. The instance goes to ERROR and the next deploy starts clean. That includes a machine the provider did make but whose answer never reached Fadebox — a create that timed out waiting for it, or an instance deleted while it was being made: before Fadebox lets such a machine go, it asks the provider for it by its name and ownership labels, and destroys it if it is there. A redeploy meanwhile is refused with machine_not_released for the length of that one destroy, then runs.
• A hiccup in Fadebox's own database is not the provider's answer. A step the provider carried out — a machine made, a start accepted — whose record Fadebox could not write is simply taken again on the next pass, and the provider treats the repeat as the same request. The machine is not failed and the deploy is not refused over it; the server log says so, at warning level.
• A machine that did become a host keeps its disk. A restart that timed out, a start the provider refused, a deploy that failed on the machine — a bad image tag, a health check that never passed: the machine is switched off, the instance goes to ERROR with the reason, and the next deploy retries the same machine and the same disk. An instance in ERROR does not count against the instance cap, so its machine is not left running either. The container logs go with it; the reason stays on the instance and in the machine log. Giving it up for good is what deleting the instance is for.
• A machine stopped or reclaimed outside Fadebox is noticed, usually within about a minute. That covers a spot or preemptible machine the cloud took back and a machine somebody stopped in the provider's console: the instance goes to ERROR saying so, with its disk kept. It is not restarted automatically — a machine that keeps being preempted is something to see, not something to retry — so redeploy the instance when you want it back.
• A stop or a destroy the provider refuses is retried slowly, every few minutes, and is never escalated into destroying a machine. A provider that will not switch a machine off has not been asked to delete it.
• So is one the provider accepted and never carried out. A provider answers a stop or a destroy once it has taken the call, not once the machine is down, so an operation that fails afterwards — or a machine somebody starts again in the console before the stop lands — leaves the machine running. Fadebox waits for the call as long as it waits for a step on the way up, fifteen minutes by default; past that the machine is flagged refused with a sentence saying what was waited for and what the provider reports instead, and the call is made again on the slow cadence. The flag stays up while the repeated call is waited on — its reason then opens Asked again and accepted, not finished yet. Before that: … — and clears only when the machine is actually stopped or gone, so a machine whose operations keep failing reads Refused the whole time. A machine that was stopped in Fadebox and then started again in the console after the stop landed is still not noticed.

Each of those steps is recorded in the audit log against the machine — created, started, stopped, destroyed, failed, expired — so a machine's timeline is also the record of the hours it was charged for. Those events are on the administration side of the audit log and nowhere a deployer looks. What a deployer reads instead is the instance's own card, and its machine log, whose last line after a failure is the reason.

The instance's card says what its machine is doing. An instance on an elastic runtime names the profile its machine was sized by beside its runtime, and carries a machine chip on the line below while the machine is doing anything but running: creating machine, machine booting, machine stopped · disk kept. A machine that is up and healthy adds nothing there. Three of the readings are about money or data rather than about a deploy going wrong, and take the card's warning colour — the first two always, the third in its last day:

• machine not stopping — the provider will not switch the machine off, so it is still running and still costing although the instance is stopped. Fadebox goes on asking; an admin can see it on the runtime's machines.
• kept after a failure — a restart failed, or the cloud took the machine away, and it was switched off with this instance's disk kept. The next deploy starts from that disk. If nobody comes back for it, the runtime's retention ends it.
• machine stopped · disk kept 5d 4h more — the countdown a retention puts on a stopped disk. It is a plain chip until the last day and amber inside it, and the hover names the moment and says that deploying before then keeps the disk.

An instance with no machine — one on a static runtime, and one that has never been deployed — shows no chip at all. The one exception is an instance whose machine retention took: it carries disk expired 2d ago in the chip's place. See stopped machines do not keep their disks for ever.

Health is read off the instance's own machine. The periodic sweep and the daemon's live event stream both reach each machine separately, so an elastic instance's health is as current as it is anywhere else. An instance whose machine is not ready — still provisioning, or switched off — reads UNKNOWN and says which of the two it is, rather than showing a verdict from before the machine went away. What a container costs is read off each machine too, so an elastic instance shows the same CPU and memory figures as one on a shared host.

An elastic runtime still shows no usage bars of its own, and that is deliberate: the bars describe a daemon — its processors, its memory, what /system/df said — and such a runtime has none. What it reports at its own level is how many of its machines answered the last reading and how many were ready and would not, so a partial picture reads as partial rather than as a quiet fleet. Disk is not read from machines at all, so a machine's images and volumes show a dash — a machine is one instance's, and it is destroyed whole rather than tidied.

Seeing the machines

A machine is a bill, and the instance that asked for it is not always still there to explain it. So an admin can list an elastic runtime's machines: every machine Fadebox has a row for, with the state it is in, when it last changed, the instance it hosts, who asked for it and the last thing that went wrong with it. It crosses every project on the runtime, deliberately — a per-project view of a bill is not a bill. A machine with no instance against it is the case the listing exists for: the instance was deleted or moved, or its stopped disk aged out, and the machine is still there.

Most machines need nothing from anybody, so the listing flags only three cases and can be narrowed to exactly those:

• Failed — the machine is finished and will be destroyed. The reason is on it, and it is the same sentence the instance is showing.
• Refused — the provider will not take a stop or a destroy, or took one and has not carried it out within the provision timeout (fifteen minutes by default), or would not list the account when Fadebox looked for a machine whose creation it never heard back from, and Fadebox is asking again on a slow cadence. The reason says which: The provider accepted the destroy 15m1s ago and still reports the machine as RUNNING; the destroy will be asked for again. It never escalates that into deleting the machine, so one stuck this way goes on billing until the provider carries out the call or somebody removes it by hand. The flag stays until the machine is stopped or gone, even while a repeated call the provider accepted is being waited on. A refused stop also stops being flagged once a deploy wants the machine running again: nobody is asking for that stop any more.
• Kept after a failure — it is switched off with its disk kept, after a restart that failed or a machine the cloud took back. The volumes are intact and the next deploy would use them, but nobody has come back for it, and the runtime's retention will eventually end that disk.

A machine that is merely slow is not flagged. Waiting is what provisioning is, and a listing that flagged everything unusual would flag half a healthy fleet.

A refused machine is the one an admin can push along: Retry now asks the sweep to make the call again on its very next pass, instead of waiting out the slow cadence, which is what you want the moment you have cleared whatever was refusing — a deletion lock, a policy, a quota — or whatever made an accepted call fail. It asks the provider nothing itself and changes nothing about what the machine is wanted to be.

The same listing is fadebox runtime machines and the API.

Machines Fadebox has no row for

Rows are one half of the answer. The other half is the cloud account itself, which Fadebox lists every ten minutes per elastic runtime and compares with what it thinks it has:

• A machine whose creation Fadebox asked for and never heard the answer to — the reply was lost, so the row exists with no handle on it — has that handle attached back, and the ordinary lifecycle carries on from there. It is the one thing a pass writes.
• An orphan is a machine carrying this installation's ownership labels that no row is tracking: a leak, billing with nothing watching it. An admin can have one reclaimed — destroyed at the provider, disk and all — and that is the only thing in Fadebox that takes a cloud machine away because somebody clicked, so it is fenced accordingly: the machines are named one at a time, at most twenty-five in a call, and every one of them is checked again against a listing taken during the call rather than against the findings the page was drawn from. A pass is minutes old, and on some platforms a handle is handed to the next machine created.
• A foreign machine is another installation's — another Fadebox on the same cloud account — or one whose ownership labels are too incomplete to say whose it is. Those are reported and never touched, whatever they look like. Two installations sharing one cloud account is a thing people legitimately do, and a cleanup that could not tell them apart would destroy somebody else's running fleet; so a machine that cannot say whose it is counts as not ours.

A machine created moments ago is not an orphan. There is a short grace period, because a machine exists at the provider for an instant before Fadebox has finished writing down that it does, and without it every deploy in progress would read as a leak.

Nothing is destroyed on a guess. A selection is refused, machine by machine with the reason on each, when the handle is no longer at the provider, when it is there under another name, when Fadebox turns out to have a row for it after all, when its labels name a row that disagrees, when they name another elastic runtime or one that has since been deleted, when the labels are too incomplete to place, and when the machine is younger than the grace. A machine the provider cannot put a date on is the one case an admin is asked to take on themselves, per machine. And a listing Fadebox could not take at all refuses the whole call: nothing is checked, so nothing is destroyed.

None of this is gated on the licence, and it does not stop when a runtime is disabled: it is what finds the machines nobody is watching but the provider's billing. Reading the listing, the findings, asking for a pass on demand and reclaiming what one turned up are in Keeping track of machines.

Stopped machines do not keep their disks for ever

An elastic runtime carries a stopped-machine retention in days. A machine that has been switched off for longer than that is destroyed, and what goes with it is the instance's data: its volumes and its warm image cache.

The instance itself is untouched — it stays STOPPED, and its next deploy comes up on a fresh, empty machine, which is the same thing that happens to an instance moved to another runtime. The default is never: a stopped disk is kept until somebody deletes the instance. Setting a retention is how an admin decides how long a cold start is worth avoiding, and it is the one deliberate way a machine goes without the instance being deleted.

The instance says so, before and after. A retention is only a spend control if the people whose data it is can see it coming, so the clock is on the card rather than in the audit log:

• While the machine is off, the chip counts down — machine stopped · disk kept 5d 4h more — and turns amber inside the last day. Deploying before that moment starts the same machine on the same disk and clears the clock; nothing else does. A deploy whose start the provider refuses — a quota, a zone out of capacity — still counts as somebody coming back: the machine stays off with its disk, and the keep starts again from that attempt, so the disk is never given up minutes after somebody tried to use it. The machines listing's since shows that moment.
• Once retention has taken it, the machine chip is gone and the card reads disk expired 2d ago in its place, saying that the volumes and the image cache went with it. The instance is still STOPPED and still deploys — it comes up on an empty machine, so it starts cold and with none of its data.
• The next deploy clears the note, because it is the instance's current state rather than its history. What happened stays in the audit log as machine.expired.

A countdown that has run out but which the hourly scan has not reached yet reads disk expiring; the disk is still there, and deploying now still keeps it.

Nobody is told out of band

Fadebox sends nothing to anybody — no mail, no alert — so all of this is seen by whoever opens the instance. A retention shortened by an admin simply reads as a nearer date the next time a card is drawn, and an instance nobody has looked at for a month is one whose owner learns about the empty disk when they deploy. On a runtime that sets a retention, telling the people whose environments live there is still worth doing.

How machines count against the license

Elastic runtimes are on every tier, and nothing about them is gated. Machines need no limit of their own, because each instance gets exactly one: an instance that is provisioning, starting or running holds a slot against the per-runtime instance cap, so the cap is also how many machines can be running on that runtime at once — 5 on Free, 10 per runtime on Team. A stopped instance's machine is switched off and keeps its disk; it does not count, and retention destroys it later if you set one. Stopping frees the slot, exactly as it does on a static runtime.

The cap is checked when you deploy, like every other limit. A license that lapses stops nothing that is running:

• Deploying, stopping, resetting and deleting instances on an existing enabled elastic runtime all keep working.
• Machines keep being created, started, stopped and destroyed by the lifecycle above, because a machine nobody destroys is a bill nobody ends.
• Reading the machines, reconciling a runtime against its cloud account, reclaiming a leaked machine and asking again about a refused one are never gated at all. Of everything here, these are the last things that should stop: a lapsed license must not stand between an admin and the end of a bill.
• Editing an elastic runtime, disabling it and deleting it all stay open.

That is the same rule every other limit follows — see what enforcement does.

On Free, the one runtime can be an elastic one: the front it needs does not have to be enabled. Setting up an elastic runtime has the steps.

What an elastic runtime does not do in v1

Beyond the unbuilt pieces listed at the top of this page, these are deliberate limits rather than gaps waiting to close. The full list, with what each refusal says, is on the guide; in short:

• No scheduling and no pooling. One instance, one machine. There is no bin-packing across machines and no pool of warm machines waiting to be claimed, which is why cold start is what it is.
• No automatic restart of a machine that was preempted or stopped behind Fadebox's back.
• No per-instance machine size, and no resize. The profile is the environment's, and it decides a machine's size when the machine is created. An instance whose machine already exists is refused a deploy under another profile until that machine is gone.
• No template test runs, no image reclaim and no host resource scan or purge on an elastic runtime, and no ingress stack of its own. Those exist for a host that accumulates leftovers, and a machine is destroyed whole.
• Host-published ports answer inside the machine network only. A service that publishes a port without going through ingress is reachable from the front's side of the network, and from nowhere else.
• One published machine image, for Google Compute Engine. A profile that names no image boots the Fadebox runtime image. Anything else — a hardened base, extra tooling, an image your organisation builds itself — is the admin's to build, under the same contract, from the reference Packer template.

One more thing is worth knowing rather than planning around: Fadebox starts a machine's ingress router while the machine is coming up, and does not watch it afterwards. Both of its containers restart themselves after a crash or a reboot, so nothing normal takes them away; but a router somebody removes by hand on a machine that is already ready is not noticed, and not put back, until that instance is next stopped and started.

Setting one up — the prerequisites, the image, the network and the calls — is its own guide.