Concepts

How Shiprr turns a Git repository into a live app, then keeps the runtime, domains, access controls, and billing understandable.

How Shiprr works#

Shiprr is a source-based app platform. You connect a Git repository, Shiprr builds the app, then runs it as one or more replicas behind managed routing. You do not choose servers directly. You choose the app settings that matter: region, CPU, RAM, replicas, start command, environment variables, domains, redirects, rewrites, and access rules.

1. Repository import connects Shiprr to your GitHub or GitLab repository. The selected branch becomes the source for deployments.
2. Build detection uses the source tree to detect supported runtimes and frameworks, then runs the managed build pipeline.
3. Release configuration applies your start command, environment variables, region, CPU, RAM, and replica count.
4. Runtime placement starts replicas in the selected region when capacity is available.
5. Routing sends traffic to healthy replicas. Custom domains, managed TLS, redirects, rewrites, IP allowlists, and basic auth are applied in front of the app.
6. Billing tracks running CPU and RAM, build minutes, and outbound bandwidth. The dashboard shows wallet activity and current month estimates.

Shiprr currently focuses on source deployments. Custom Dockerfiles, prebuilt container image deploys, background workers, and persistent disks are not supported yet.

Replicas#

A replica is one running instance of your app. You can scale from 1 to 50 replicas. Each replica gets its own CPU and RAM settings and runs your start command. Traffic is distributed across replicas by the platform. Use more replicas for higher throughput or zero-downtime deploys.

CPU and RAM#

You choose CPU (1,000–20,000 MHz per replica in 1k steps) and RAM (512 MB–16 GB per replica). New apps start at 1,000 MHz and 512 MB, which is a light baseline for small APIs and simple services. Heavier stacks like SSR frameworks, Rails, or Java apps usually need more headroom, often 2,000 MHz and 1 to 2 GB as a better starting point. Billing is pay-as-you-go: you pay for the CPU and RAM you allocate, per hour of run time. Idle replicas still consume their configured resources, so scale down when you do not need the capacity. See Pricing for rates.

Scaling#

Adjust CPU, RAM, and replica count in the dashboard under your app → Resources. Use more replicas for higher throughput or zero-downtime deploys. Add more CPU or RAM if the app is saturated or hitting limits. Scale down to reduce cost when traffic is low. Saving applies the change to your production app.

• More replicas — Higher request volume, zero-downtime deploys, or redundancy.
• More CPU — Build or runtime is slow or CPU-saturated.
• More RAM — Out-of-memory errors or larger caches.
• Scale down — Lower traffic or cost by reducing replicas, CPU, or RAM.

Build vs. run#

Build is the step where we install dependencies and compile your app (e.g. npm install, npm run build). Build runs on dedicated builder capacity with 4 CPU and 10 GiB memory, and is limited to 25 minutes per run. The first 50 build minutes per month are free. After that you are charged per minute.

Shiprr builds from source repositories using its managed build pipeline. Custom Dockerfiles and prebuilt container images are not supported yet.

Run is the long-lived process that serves traffic. We start your app with the command you configure (e.g. node server.js). You are billed for CPU and RAM for the time each replica is running. New apps start with 1,000 MHz and 512 MB per replica, and you can increase that later if the app needs more memory or throughput.

Regions#

You deploy to a region. Shiprr currently supports eu, us, oc, and asia. The selected region is a placement preference and custom-domain routing target. Shiprr prefers matching regional capacity first, but may fall back to another configured region if the preferred region has no capacity. Pick the region closest to your users or your database to reduce latency.

Ephemeral storage#

Replicas have no persistent disk. Anything written to the filesystem is lost when a replica restarts or redeploys. Use an external database (Postgres, MongoDB, etc.) and object storage (S3, R2) for persistent data. We do not charge for ephemeral disk used during build or run.

Egress#

Egress is outbound traffic from your app (e.g. responses to users, calls to external APIs). The first 100 GB per month is free. After that it is EUR 0.005/GB in EU/US and EUR 0.02/GB in APAC/Oceania. Inbound traffic is free.