Deploying apps

A service is one deployable app built from a Git repository. Connect the repo, tell Gheima how to build and start it, and it redeploys on every push.

1. 01

   Push

   A commit lands on the branch you configured.

2. 02

   Build

   Nixpacks auto-detects your stack, or your own commands run.

3. 03

   Deploy

   The new version replaces the running one.

4. 04

   Live

   Logs stream on the service page.

Connect a Git repository#

1. 1

   Choose from GitHub

   After you connect the GitHub App, pick a repository from the dropdown. The clone URL and default branch fill in automatically.

2. 2

   Or enter a URL

   Click “Enter a URL manually” and paste a Git URL like https://github.com/you/repo.

Build & runtime settings#

Open the service’s Settings tab. Leave the build and start commands blank to let Nixpacks auto-detect your stack, or set them explicitly.

Build command

The command that builds your app, for example npm run build. Leave it blank to let Nixpacks detect it.

Start command

The command that starts your app, for example npm start. Leave it blank to let Nixpacks detect it.

Port

The port your app listens on. Default 3000 for web services.

Health check path

A path that answers with a 2xx or 3xx status when the app is healthy, for example /health. The default is /.

Auto-deploy on push#

In Settings, "Auto-deploy on push" is on by default. Every push to the configured branch triggers a new deployment that records the commit SHA, message, and author. Turn it off to deploy only by hand or through a deploy hook.

Service types#

Web

An HTTP service served on a gheima.ma subdomain. This is the default.

Worker

A background process with no public URL (queues, jobs).

Static

A static build served on the edge. See Static sites.

Resources#

The Resources card in Settings sizes each service: replicas (1 to 10), memory (128 to 8,192 MB), and CPU (0.1 to 8 vCPU). Changes apply on the next deploy, within your plan’s limits. Your plan includes a memory pool shared by all your services: memory × replicas, summed across services (static sites excluded). A new service starts at the default size, or at what is left of the pool when that is less; with under 256 MB left, shrink or remove a service first.

Persistent volumes#

In a service’s Settings, attach a persistent volume at a mount path, for example /data. It is a disk on the node that survives deploys and restarts, so files written there persist. Changes take effect on the next deploy. A volume suits a service that runs one replica. A service that scales out should use a managed database or object storage instead.