Openship
ChangelogResources
Guides

Sleep mode & resources

Tune what your app costs and how it performs — pick how much CPU, memory, and disk it gets, and choose whether it sleeps when idle or stays on all the time.

Think of your deployed app like a rented room. Two things decide what it costs and how it feels to visitors: how big the room is (how much CPU, memory, and disk it gets) and whether the lights stay on all the time or switch off when nobody's there (sleep mode). This guide shows you how to set both.

Neither setting changes your code — they only change how the machine behind your app runs. You can adjust them at any time.

What you need first

  • A project you've already deployed (see Your first deployment if not).
  • For the CLI examples, the openship command installed and logged in.
  • The project ID for the CLI/API bits. Run openship project list to find it.

The two settings, in plain words

  • Resources — the size of the machine: how many vCPU (processing power), how much RAM (working memory), and how much disk (storage) your app gets. Bigger means faster and able to handle more at once, but costs more.
  • Sleep mode — what happens when your app is idle:
    • Auto Sleep (the default) — the app stops when no one is using it and wakes up on the next request. Cheaper to run, and Openship wakes it instantly, so visitors don't wait.
    • Always On — the app never stops. Highest availability, but it's running (and costing) around the clock.

Which sleep mode should I pick?

Start with Auto Sleep. It's the recommended default and right for the large majority of apps. Switch to Always On only if you have a specific reason — for example a background job that must keep running, or an app that can't tolerate the brief wake-up on the very first request after a quiet spell.

Set resources

Resource sizing lives in the deploy screen, under a section called Power, when you deploy to Openship Cloud — and on any existing project under Machine Power (Configuration tab, or the Services tab for a multi-service project). You can also set it from the API.

Self-hosted: no limits by default

A self-hosted container is uncapped unless you say otherwise — the machine is the ceiling, because it's your hardware. Pick a tier (or No limits, the default) only when you deliberately want to cap a container. A non-zero value is checked against the target machine's real capacity, so a 64 GB box can hand a container 64 GB.

Builds are uncapped too. Capping a build is opt-in via the build field below, and is really only useful on a small box where an unbounded production build would otherwise take the whole host down.

Openship Cloud is the opposite: a workspace is metered and must be sized, so there's no "no limits" option there and an unset project falls back to the Low tier.

Start a deploy and choose Openship Cloud

Begin a deployment as usual. When you reach the "Where do you want to deploy?" choice, pick Openship Cloud. A Power section appears next to it — this is where you pick the machine size.

Pick a size

Choose one of the ready-made sizes. Each shows its vCPU, RAM, and disk:

SizevCPURAMDisk
Micro0.25256 MB4 GB
Low0.5512 MB8 GB
Medium11 GB16 GB
High22 GB32 GB

If none fit, pick Custom and type your own vCPU, RAM (in MB), and disk (in GB).

Not sure?

Smaller apps and side projects are happy on Micro or Low. Medium suits most production apps. Reach for High only for heavy traffic or slow builds. You can change size later, so start small.

Screenshot

The deploy screen with Openship Cloud selected and the Power section showing the Micro / Low / Medium / High / Custom size cards. (screenshot pending)

Deploy

Finish the deploy. Your app runs at the size you picked.

Any existing project has a Machine Power card. On a single app it's under Configuration; on a multi-service (compose) project it's on the Services tab, since that project shape has no single-app Configuration.

The card shows the target machine's detected capacity in its header, and offers:

  • No limits — the self-hosted default. The container gets the whole machine.
  • Micro / Low / Medium / High — the same presets Openship Cloud offers. A preset larger than the machine is greyed out rather than silently unhonored.
  • Custom — type your own vCPU and MB. 0 in either field means no limit for that dimension, so you can cap memory while leaving CPU free.

Limits apply when the container is recreated, so redeploy for a change to take effect. The card says so inline. Every deploy also logs the limits it applied (Resource limits: 2 vCPU · 4 GB, or no limits (machine capacity)), so a cap is never invisible.

A service in a compose project can override the project value for itself — see per-service limits.

Update an existing project's resources with a PATCH to its resources endpoint. All paths are under /api on your instance (for example https://your-host/api/...). Authenticate with a personal access token in the Authorization header — create one from Settings → Tokens or with openship token create. See Authentication for the full token model.

You can set the production size (what your live app runs on) and, separately, the build size (the temporary machine that compiles your app). Sizes are given as cpuCores, memoryMb, and diskMb.

curl -X PATCH https://your-host/api/projects/PROJECT_ID/resources \
  -H "Authorization: Bearer $OPENSHIP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "production": { "cpuCores": 1, "memoryMb": 1024, "diskMb": 16384 },
    "build":      { "cpuCores": 2, "memoryMb": 2048, "diskMb": 16384 }
  }'

You can also send {"tier": "medium"} instead of explicit numbers, or {"tier": "unlimited"} (self-hosted) to remove the caps.

0 means no limit. A non-zero cpuCores must be at least 0.25 and memoryMb at least 128; the UPPER bound is the target machine's own capacity, not a fixed number — so a large self-hosted box is usable in full. diskMb is 64–204800 and only enforced by cloud workspaces. Every field is optional — send only what you want to change.

GET /api/projects/PROJECT_ID/resources reads the current values, and also reports the detected machine capacity (the ceiling) plus requiresLimit (true on cloud, where unsized isn't allowed).

Per-service limits (compose)

In a multi-service project the project-wide value applies to each service container — it's a per-container cap, not a budget split across them.

A single service can override it. Openship reads a compose file's own limits, in either spelling, and applies them over the project value field by field — so a service that declares only memory keeps the project's CPU setting:

services:
  api:
    image: my/api
    mem_limit: 4g          # short form
    cpus: 2
  worker:
    image: my/worker
    deploy:                # swarm form — also honored
      resources:
        limits:
          memory: 8G
          cpus: "1.5"

The same override is available declaratively in openship.json under services[].resources.

Adopted containers keep their limits

Importing an existing Docker container reads the caps it's actually running with — including one you applied by hand with docker update --memory — so adoption doesn't quietly reset them.

Set sleep mode

Sleep mode has two values: auto_sleep (the default) and always_on. Set it from the CLI or the API.

# Let the app sleep when idle (the default, cheapest)
openship project sleep-mode PROJECT_ID auto_sleep

# Keep it running around the clock
openship project sleep-mode PROJECT_ID always_on

Don't know your project ID? openship project list shows every project with its ID.

curl -X POST https://your-host/api/projects/PROJECT_ID/sleep-mode \
  -H "Authorization: Bearer $OPENSHIP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "sleep_mode": "always_on" }'

sleep_mode must be auto_sleep or always_on. (You can also change it alongside resources by sending a sleepMode field to PATCH /api/projects/PROJECT_ID/resources.)

Sleep mode is about a running server

Sleep mode matters for apps with a running process (a server or API). A purely static site has nothing to put to sleep — it's just files being served — so the setting has no visible effect there.

If something goes wrong

A resource value is rejected

A cap larger than the target machine is refused with the real numbers, e.g. Memory limit 8192 MB exceeds the machine's 2048 MB. Lower the value, or use 0 / the unlimited tier to remove the cap. A non-zero value below the workable floor is refused too (at least 0.25 cores, at least 128 MB). If Openship couldn't reach the machine to read its capacity, no ceiling is enforced at all — the value you send is accepted as-is.

Sleep mode command is rejected

The mode must be exactly auto_sleep or always_on — nothing else. Check the spelling (both use an underscore), and make sure the project ID is right. openship project list confirms both.

I made it Always On but costs went up

That's expected — Always On keeps the machine running 24/7. If you don't need constant availability, switch back with openship project sleep-mode PROJECT_ID auto_sleep and the app will sleep when idle again.

What next?

Deploy to your own server

Run your app on a machine you control instead of Openship Cloud.

Logs & monitoring

Watch how your app behaves so you know when to size it up or down.

Rollback & redeploy

Ship a new version, or go back to a working one, in seconds.

Connect to Cloud & migrate

Link the copy of Openship you run yourself to Openship Cloud, move a single project up or bring it home, and (at a high level) open your instance up to a whole team.

Updating Openship

Keep your Openship up to date — the one-click desktop updater, the CLI update command, and how the always-on service picks up a new release.

On this page

The two settings, in plain wordsSet resourcesStart a deploy and choose Openship CloudPick a sizeDeployPer-service limits (compose)Set sleep modeIf something goes wrongWhat next?