shiprr.
Log in Create account

Deploying apps

How to configure builds, set environment variables, choose regions, scale replicas, and add custom domains.

Build and run#

Shiprr infers the runtime from your project (e.g. package.json, requirements.txt, go.mod). You can override the root directory, install command, build command, start command, and health check path in the dashboard under App → Settings → Build & Runtime.

root directory: apps/web
install command: pnpm install
build command: pnpm build
start command: pnpm start
health check path: /health

Build, start command, and health check changes are saved immediately, then apply on the next deploy or app restart.

New apps start with 1,000 MHz CPU and 512 MB RAM per replica. That is enough for small services, but SSR frameworks, Rails, and Java apps often work better with 2,000 MHz and 1 to 2 GB as an initial setting.

If no health check path is set, Shiprr uses a TCP check on the app port. If you set a local path like /health, Shiprr uses an HTTP readiness check against that path on your app. Checks run every 15 seconds with a 3 second timeout. New deployments get a 60 second startup grace period and up to 3 minutes to become ready.

Builds use the Shiprr source build pipeline. Custom Dockerfiles and prebuilt container image deploys are not supported yet. For runtime and framework compatibility, see Supported apps.

Build minutes#

Build runs in a container with your dependencies. The output is then run with the configured start command. Builds use dedicated builder capacity with 4 CPU and 10 GiB memory, and are limited to 25 minutes per run. The first 50 build minutes per month are free.

First builds are usually slower because dependencies and build layers need to be fetched and cached. A typical first build may take around 2 minutes. Later builds of the same app are often much faster, commonly around 30 seconds, depending on dependency changes, framework, and repository size.

Environment variables#

Set env vars in the dashboard under App → Settings → Environment variables. For key formats and limits, see Configuration.

Saving redeploys the app so the new values take effect. Values are masked in the dashboard until revealed by an authorized user. Avoid printing secrets from build scripts or app code because anything your process writes can appear in logs.

Regions#

Choose the region closest to your users or database. Shiprr uses that region as a placement preference and custom-domain routing target. If the preferred region has no capacity, the platform may place replicas in another configured region.

Automatic deployments#

In App → Settings → Continuous Deployment, choose whether Shiprr deploys on branch pushes, tag pushes, or only when you trigger a manual deploy.

Scaling replicas#

In the dashboard, open your app → Resources. You can set:

  • CPU — 1,000–20,000 MHz per replica (1k steps)
  • RAM — 512 MB–16 GB per replica
  • Replicas — 1–50 app instances (horizontal scaling)

Billing is pay-as-you-go: you pay for CPU and RAM per hour of run time. For the scaling model and when to scale, see Concepts → Scaling.

Access and routing#

You can also configure edge access restrictions and path-based routing from app settings:

Custom domains#

Add a custom domain in the dashboard under your app → Domains. Shiprr supports both subdomains and root domains, and provisions TLS automatically after DNS is pointing at Shiprr. For the exact DNS patterns, SSL timing, and setup examples, see Custom domains.

Egress and storage#

The first 100 GB of outbound traffic per month is free. After that it is EUR 0.005/GB in EU/US and EUR 0.02/GB in APAC/Oceania. There is no persistent disk: use an external database (Postgres, MongoDB, etc.) and object storage (S3, R2) for persistent data.