How deploys work

Two ways to buildCopy Anchor Link

grey deploy picks one for you:

On your machine, grey compiles each service for Greyship's Linux CPU:

CGO_ENABLED=0 GOOS=linux GOARCH=<server cpu> go build -trimpath -ldflags="-s -w"

A compile error stops the deploy before anything is sent. go vet runs at the same time; its warnings are printed but never block the deploy. Greyship then checks every binary: it must be a static Linux binary for the right CPU, built with -trimpath, matching the checksum grey declared.

On Greyship, grey packs the folder and uploads it. It honours .gitignore and .greyshipignore, and never uploads .git, node_modules, symlinks or any .env / .env.* file, whatever the ignore files say. The compressed source can be at most 100 MB; above that grey lists the biggest files. Modules come from the public Go module proxy, checked against the Go checksum database. Private modules aren't supported yet.

The stepsCopy Anchor Link

1. Detect. Greyship reads your code and lists the services it found and why. Nothing is run.
2. Env vars. If you have a .env.prod, grey compares it with the stored variables and shows a key-only diff before anything changes. See Environment variables.
3. Build or upload, as above.
4. Release command. If the project has one (for example cmd/migrate), it runs once, before any traffic switches. See Release command.
5. Start and check. Every service starts on fresh instances. A web service must start listening for connections within 30 seconds (on any port, see Ports); a worker must still be running after a few seconds.
6. Switch. Only when every service is healthy does traffic move to the new version, all at once. The previous version's instances then stop.

grey deploy follows all of it live and ends with ✓ Live and the URLs. The dashboard shows the same log.

All or nothingCopy Anchor Link

A deployment covers every service in the project together. If one service fails its health check, nothing switches: the deployment is marked failed and the live version keeps serving every service. This keeps services that depend on each other (sharing a database schema, calling each other) on the same version.

The log says exactly what visitors get:

  │ deploy failed: api didn't start on eu-1: health check failed: the app exited with code 1 before it started listening
  │ nothing changed: the live version (deployment d7685c76) keeps serving

The app's last output lines appear just above, so you usually see the cause right there (a missing env var, a panic).

Projects and the link fileCopy Anchor Link

The first grey deploy (or grey init) in a folder creates the project and writes .greyship/project.json next to go.mod:

{ "team": "you", "project": "shop", "id": "…" }

It holds no secrets; commit it so teammates and CI deploy to the same project. The project name comes from the last part of your module path (github.com/acme/orders-api → orders-api, a /v2 suffix is dropped), lowercased with dashes. Use grey init --name … to pick another before the first deploy. If the name is taken in your team, grey asks whether to deploy to the existing project.

Build limitsCopy Anchor Link

More in Limits.

Rename or delete a projectCopy Anchor Link

Open the project in the dashboard and choose Settings. You can rename it there (its services' addresses follow the new name), or delete it: type the project's name to confirm and it disappears at once. Its apps stop and its deployments, env vars, logs and stored files are removed in the background. This can't be undone.

From the terminal: grey projects delete <name> asks you to type the name too, or takes --yes in scripts.