Builds

Every deploy turns your source into a container image and rolls it out. This page covers what happens in between: the states a deployment moves through, why it sometimes waits, what a build gets to work with, and what to do when one takes too long.

The states a deployment moves through

ghayma deploy keeps one line going while the deployment moves through these states — a dot every few seconds — then prints the result:

🚀 Deploying my-app..............................
✅ Deployed successfully!
🌐 Your app is live at:
   https://my-app.ghayma.app

Each state appears on your project’s Deployments tab in the dashboard .

Waiting for a slot

The platform builds a limited number of deployments at a time. When those slots are all busy, your deployment waits its turn as Queued, and the CLI keeps adding dots.

A queued deployment means build capacity is momentarily full — nothing is wrong with your project. There is nothing to do but wait; queues normally clear in seconds to a couple of minutes. Your source is already uploaded and safe, and the site you have live keeps serving throughout.

Who goes first

Two rules decide the order:

• Paid plans are prioritised over free plans. When a paid and a free deployment are both waiting, the paid one is served first. Free-plan builds are not starved — they keep getting slots, just a smaller share of them while paid deployments are queued.
• At most two builds per project at once. However many deploys you fire off together, your project uses at most two build slots and the rest of your deployments queue behind them. This is what stops one busy project from filling the platform while everyone else waits — including when the busy project is somebody else’s.

What a build gets

A build that has not finished within 20 minutes is stopped and the deployment is marked failed. Nothing about your running site changes — the previous build keeps serving.

ghayma deploy waits up to 25 minutes in total (the queue plus that 20-minute limit). If it gives up first, the build itself carries on inside the platform; open the deployment in the dashboard to see how it ended.

Why repeat builds are fast

Builds of the same site reuse what the last one produced:

• Layers are cached between builds. A step whose inputs have not changed is not run again — so if you only changed application code, your dependency install is reused rather than repeated.
• Base images are mirrored inside the platform, so the images your build pulls from don’t cross the public internet every time.
• Finished images are compressed with a faster algorithm before they’re stored, which cuts the tail end of every build.

The first build of a new site has nothing to reuse, so it is the slowest — several minutes is normal, and it is not a sign of trouble. Later builds of the same site are typically much faster.

What legitimately invalidates the cache: changing your lockfile or package.json (the install layer is meant to rebuild), and editing the early lines of a custom Dockerfile — everything after the line you changed rebuilds too, which is why installs belong near the top of a Dockerfile and source copies near the bottom.

If a build times out

Using your database during the build

A build can reach the databases its site is connected to, and it receives their variables — DATABASE_URL and the rest — as build secrets: there while the build runs, never written into the image. A Valkey is the exception: no build reaches it (see Valkey). A prebuild script running prisma migrate deploy therefore works with no setup on a build Ghayma generates; a custom Dockerfile mounts the variables on the steps that need them. See Using your database during the build.

Related

• Deploy & Manage — the ghayma deploy command and what gets uploaded
• Using your database during the build — migrations and other database work in a build
• Custom Dockerfile — bringing your own build
• Points & Plans — what each plan includes