Deploy from a Git repo

The usual way to run something on Ruust is to point us at a Git repository. You connect the repo, we detect the stack and build it, and the result runs as an Egg. Every Egg belongs to a Coop (your project), so related Eggs stay grouped together. This page covers the repo-to-Egg flow: connecting a repo, choosing a branch, deploying from a subdirectory, and redeploying.

Deploy it

1. Push your app to a Git repository (GitHub or any repo Ruust can reach).
2. In the dashboard, choose New Egg and connect the repository.
3. Pick the branch to deploy from (the default is your default branch).
4. Choose a Coop for the Egg, or create a new one.
5. Pick a size and a region (London or Virginia, or your own byo host), then lay the Egg.

What Ruust detects

Once the repo is connected, Ruust builds it with Nixpacks, which auto-detects the stack from the files in the repo (a package.json, a Gemfile, a go.mod, and so on), installs dependencies, runs any build step, and chooses a start command. If the repo has a Dockerfile at the build root, Ruust builds that instead and leaves the rest to you.

Choosing a branch

Each Egg tracks one branch. Deploy main for production and lay a second Egg from a staging branch if you want a preview that shares the same repo. To move an existing Egg to a different branch, change the branch in the Egg settings and redeploy.

Deploying from a subdirectory (monorepo)

If your repo holds several apps, set a root directory on the Egg and Ruust builds from there. Detection, the build, the Dockerfile lookup and the Procfile all resolve relative to that directory, so each app in the monorepo becomes its own Egg with its own root.

my-repo/
  apps/
    web/      <- set this as the root directory for the web Egg
    worker/   <- a second Egg, root directory apps/worker
  packages/
    shared/

The port

Whatever the stack, one rule decides whether the Egg hatches: Ruust sets a PORT environment variable, and your app must listen on it and bind to 0.0.0.0 (not localhost). Binding to localhost or a hard-coded port is the top reason an Egg builds cleanly but never hatches.

const port = process.env.PORT || 3000;
app.listen(port, '0.0.0.0');

Pinning the start command

If detection picks the wrong command, pin it with a Procfile at the build root. Its web line becomes the process Ruust runs for the Egg.

web: node server.js

Redeploying a new version

To ship a new version, push to the branch the Egg tracks and trigger a deploy from the dashboard. Ruust builds the new commit and, once it hatches, cuts traffic over to it. Because an Egg is a long-running server with no cold starts, the previous version keeps serving until the new one is live.