Deployment errors

These failures all come after your build command succeeded, while the result is packaged, provisioned and published. The status can still read Building, because packaging is the tail of that stage, and the fix is in what your config declares or how large the result is rather than in your build script.

An entrypoint file is missing

Symptom. The build command succeeded and the deployment failed anyway, still under the build-and-package stage:

Entrypoint "build/server/index.js" configured in gigadrive.yaml does not exist in the project. Check the "entrypoint" setting and your build output.

When the entrypoint came from a framework preset rather than your config, the message names the framework and the path that preset expects by default.

Cause. Every Function points at a file in the built tree, and nothing produced that file. The usual reasons are a build that wrote its output somewhere else, a static export that produces no server file at all, a root directory one level off, or a config that names a source file which the build compiles to a different path.

The check covers Node and Bun entrypoints only. A PHP entrypoint that does not exist gets through it and fails later, during packaging, with a less specific message.

Fix. Name the file that exists after a local build. The key of each functions entry is the entrypoint path:

version: 4
functions:
  build/server/index.js:
    runtime: node-22
    memory: 512

The artifact is too large

Symptom. One of two messages, both giving the measured size:

Build artifact archive size (8801MB) exceeds the deployment archive budget (8192MB). Reduce the files produced by your build before deployment.
Extracted build artifact size (9420MB) exceeds the deployment artifact budget (8192MB). Reduce build output, dependencies, or generated assets before deployment.

Cause. Two budgets of 8 GiB guard the artifact: one on the compressed archive that leaves the sandbox, one on the extracted tree. Everything the build left in the project counts towards them, including files no Function imports.

Fix. Cut what the Function does not need at runtime: test fixtures, sample data, committed binaries, and a second copy of a framework's output left behind by an earlier build. excludeFiles on a Function's config entry keeps named globs out of its package.

Provisioning fails

Symptom. [provision-and-publish] Provisioning and publishing failed, followed by either a message you can act on or a bare label such as Provisioning failed (<phase>), Failed to package function for deployment or Failed to upload deployment assets. The actionable one looks like this:

Function memory limit exceeded
Function api/index.js requests 8192 MB of memory, but the current plan allows up to 4096 MB per function. Lower the function's "memory" setting or upgrade your plan.

Cause. The plan cap is checked before packaging, against the effective memory of each Function rather than the number you wrote: at least 256 MB, rounded up to an even number.

A bare label is a platform-side failure instead, and it stays bare on purpose: internal failure detail is kept out of your log. Redeploy, and if it repeats, contact support with the deployment ID.

Fix. Lower memory for the named Function or move to a plan with a higher cap; the numbers are in Memory and CPU. Deployments already serving are untouched, so a plan downgrade only bites on the next deploy.

The deployment waits for compute capacity

Symptom. The status sits at Waiting for capacity and the Overview tab reads "Build completed. Waiting for compute capacity." with one of these reasons:

Cause. The build finished and the artifact is ready, but no host could take the workload yet. This is a durable waiting state rather than a failure, and it is retried without you doing anything.

Fix. Wait. Two things end the wait early, and both are yours: pushing a newer deployment for the same branch marks the waiting one Failed as superseded, and Cancel in the deployment's actions menu marks it Failed and withdraws the capacity request.

Hostnames and aliases

Symptom. Saving a production hostname label in Settings, Domains fails with "Enter a valid hostname label.", "This hostname label is reserved." or "That hostname is already taken. Try a different label."

Cause. A label is one DNS label under gigadrive.app and the rules are strict. No dots, because the certificate covering that namespace is single level. Three to 63 characters after normalization. Lowercase letters, digits and internal hyphens only. It may not contain -git-, which is reserved for branch aliases, it may not be one of the reserved words, and it is unique across every application on the platform.

Fix. Pick another label. Renaming has two consequences worth expecting. Branch aliases are built from the same label as {label}-git-{branch}, so every branch URL changes with it and the old hostnames are released for someone else to claim. And the new production hostname only starts routing immediately when the application already has a deployment that reached Ready. Without one, the toast says the hostname is reserved and will go live after your next production deployment.

Two more alias problems show up without an error next to them:

• A deployment is Ready but a URL still serves the previous build. Production and branch aliases are re-pointed in the publication step, and the branch alias is best effort so that a branch problem can never hold up production routing. An alias that lags behind its newest Ready deployment is re-pointed automatically, within about 10 minutes.
• The deployment failed at publish-deployment-aliases. The log line is Deployment alias publication failed cache invalidation. A deployment is only marked Ready after publication is confirmed, so this one never took over an alias.

Each deployment also keeps its own permanent URL, which is unaffected by these alias failures and always serves the exact build it was created from. Deployment URLs covers the three hostname shapes.

Once a deployment reaches Ready, failures belong to the Function rather than the deployment; see Function errors.