Our Build Sandbox Got No Address

If your deployment says Our build sandbox got no address, we could not give the machine that runs your build a network address, so the build never started. That is a fault in our build…

If your deployment says Our build sandbox got no address, we could not give the machine that runs your build a network address, so the build never started. That is a fault in our build infrastructure. Nothing in your repository, your environment variables or your project settings caused it, there is nothing there for you to change, and in most cases another attempt is already on its way without you asking for one.

This guide explains what that address is for, the two ways we can fail to provide one, how we know the fault was ours rather than yours, why there is almost no build log, what we do about it automatically, and the one case worth bringing to us.

What the Address Is For

Every Orbit build runs in its own microVM: a real virtual machine with its own kernel, booted for your build and destroyed when it finishes. One build, one machine, then gone.

That machine needs an address on the build network before it can be useful, because a build fetches things. Package registries, container layers, your private dependencies, the source archive itself: all of it arrives over that network. The address is handed to the machine by the build host as it boots, out of a pool the host keeps, and the host is the only thing allowed to choose it.

That last point is the whole design, and it is worth a sentence. An address has to be unique on the host, and only the host can know which ones are already taken. A machine that picked its own could pick one another build was already using, and two machines sharing an address break each other's connectivity in a way that looks like neither of them: a build that works, then hangs, then works, with nothing in anyone's logs pointing at us. So a guest is never permitted to guess. If it was not handed an address, it refuses to run, and you get a message instead of a mystery.

What Actually Happened

One of two things, and both of them are ours.

The host had no address left to give. Every address in the pool was held by a machine still alive. The host refuses the job outright, before any machine is booted for you, so your build has not started and nothing of yours has run. The pool holds far more addresses than the number of builds we allow to run at once, so this is not ordinary pressure and it is not a sign you asked for too much. It means something on our side was holding addresses it should have released, which is exactly why we made it loud rather than tolerated.

A machine was booted without one. The host started a guest but the address never reached it. The guest checks for that before it announces itself as ready, refuses, and shuts down, so the platform never hands it a job. This is what a mismatch between two pieces of our own build-host software looks like from the outside.

To you these are one event, so we deliberately say the same sentence about both rather than exposing you to a distinction that is only ours to care about.

Why We Can Say This One Was Ours

"It was our fault" is a claim a platform should have to earn, so here is the ground for it.

Most build failures are classified by reading text that somebody else wrote: your compiler, your package manager, a registry. That reading can be wrong, and a category built on it can be argued with. This one is different. It is decided by a marker that our own code writes about our own infrastructure, on both of the paths above. Nothing in your build output is consulted at all.

That cuts in both directions, which is the point. A repository that happens to print the words "no guest address" in a test fixture cannot hand itself a verdict of "this was the platform's fault". And a future reword of one of our own log lines cannot quietly make this category stop appearing, which is how a failure like this goes back to being filed as an unknown error.

We should also say plainly why a refusal exists to be read at all. The older behaviour was for a machine to derive its own address, and that could collide. Nobody was told. A loud refusal you can read is a worse day and a better product than a silent collision you cannot.

Why Your Build Log Is Empty

The decision is taken before any of your commands run. On the first path it is taken before a machine exists; on the second, before the machine was ready to be given work. Either way your repository had not been downloaded, your install step had not started, and the build log holds nothing, or a single line of our own start-up.

Nothing was truncated and nothing was hidden from you. Usually an empty build log means a build that printed nothing, which sends you to inspect a build command that was working fine. Here it means the build never began.

For what a full log normally contains and how to read it, see Viewing Build Logs.

What We Do About It Automatically

We try again. This is one of the few failures caused by us that is worth retrying, and the reasoning is worth stating because it is the same reasoning that makes us refuse to retry others.

We do not retry a failure that will reproduce itself. If our network policy refused a destination, the same policy refuses it next time. If a configured root directory does not exist, it does not exist next time either. Retrying those spends your build minutes to reach an identical result.

A missing address is the opposite shape. Addresses return to the pool when the machines holding them are gone, and the next attempt allocates again from a pool in a different state, on a host chosen again. It is not a repeat of the same attempt, it is a genuinely different one.

What that looks like on your deployment depends on where the refusal happened:

If the deployment is still queued, nothing failed. The host declined the job before your build started, and the deployment is waiting to be dispatched again.
If the deployment failed, we queue another one ourselves.

Two details about that matter to you:

It happens even if your project has automatic retries switched off. The project-level retry setting governs whether you want your build minutes spent again on a failure with your name on it. This is not that. You did not opt into it, you could not have prevented it, and you could not see it coming. If you have configured more retries than we add, your setting still applies: we raise a floor, we never lower your ceiling.
It is bounded at one. We will not silently loop. One further attempt is enough to tell a passing shortage apart from something that fails every time, and the second failure is evidence that should reach a person rather than be eaten by a retry loop.

The deployment page tells you which of these you are in. If another attempt is queued it says so and you need do nothing. If it is not, it invites you to deploy again when you are ready.

We are not going to tell you how long to wait, because we have not measured a figure honest enough to publish. What we can tell you is what the page shows: if it says an attempt is queued, that attempt is real.

What You Should Do

In order:

Usually, nothing. If the page says another attempt is queued, wait for it. The new deployment appears in the project's deployment list.
If nothing is queued, deploy again. The next attempt allocates an address from scratch, which is generally all it takes.
Do not go looking for the cause in your project. There is nothing there to find. Changing your build command, your dependencies, your environment variables or your network settings in response to this will not make it less likely, and it risks breaking something that currently works.
If it happens more than once on the same project, open a ticket and quote the reference. That is the case we want to see, and a second occurrence is a different fact from a first one.

The Reference You Were Given

The message ends with a short reference code. It is not an error to look up, and there is no page that explains it: it is a correlation id that ties the sentence you read to the complete record of the event in our own systems, including the host involved and the state of the pool at that moment.

We keep that detail off your screen on purpose. A failure message is stored at the moment it happens and can never be re-rendered in another language afterwards, so our internal text on your page would be our incident, in English, in front of you permanently, whatever language you read the rest of the panel in. The reference is how the detail stays reachable without being printed at you. Quote it in a ticket and the question becomes a single lookup.

What This Is Not

This category is kept narrow so that it cannot absorb failures that belong to somebody else:

A build that ran and exhausted the machine's memory is Out of memory, not this.
A build whose outbound connection our policy refused is Blocked by our policy, and that one we do not retry, for a reason set out in its own guide.
A machine that started your build and then stopped answering is Our build sandbox failed. That one had an address and was running your work. This one never started.
A build that ran to completion and exited non-zero is your build failing, and we file it as whatever it was.

This category claims only the case where our own infrastructure reported that it could not give a machine an address, decided before a single command of yours had run.