Apps & services
Everything you run on Koo fits a small hierarchy: your account contains apps, apps contain services, and services have deployments. This page gives you the mental model; the task guides build on it.
The resource model
| Resource | What it is | ID looks like |
|---|---|---|
| Account | Your tenant and your public channel — handle, profile, members, plan | acct_… |
| App | A project: a group of services with one public URL | app_… |
| Service | A running unit inside an app: web, Postgres, or Redis | svc_… |
| Deployment | An immutable version of a service | dep_… |
An account is both the billing tenant and the public identity people follow on the showcase — see Your profile and Teams & roles.
An app is a project. It groups the services that belong together and exposes one public URL.
A service is something that runs: a web service running your container, or a managed Postgres or Redis instance.
A deployment is created every time you deploy a container. Deployments are immutable versions, so you can roll back to a previous one.
Every resource has a stable, prefixed ID. The full object shapes are in the API reference: Environment, Service.
Apps
Each app has a slug, unique within your account, that forms its URLs.
Apps are public or private. Public apps get an app page on the showcase, where anyone can view, comment, and upvote. Private apps are hidden from the showcase; private visibility is a paid feature — see the plan comparison.
An app exposes exactly one primary web service at its public URL. Any other web services in the app are internal, and Postgres and Redis services are always internal.
Services
There are three service types:
- Web — runs your container image and handles traffic at the app's URL. You configure the port, environment variables and secrets, and replica scaling (a minimum and maximum count).
- Postgres — a managed database. Its connection string is injected into your web services as an environment variable.
- Redis — a managed cache and key-value store, with the same connection injection.
Postgres and Redis services are never reachable from the internet. Only services inside the same app can connect to them.
Resources
Each service declares explicit CPU and memory, picked from a discrete ladder — 0.25 and 0.5 vCPU, then whole vCPUs; 256 MiB and 512 MiB, then whole GiBs; memory up to 8 GiB per vCPU. The monthly price is linear in CPU + memory. Some example combinations:
| vCPU | Memory | Price |
|---|---|---|
| 0.25 vCPU | 512 MiB | $5/mo |
| 0.5 vCPU | 1 GiB | $10/mo |
| 1 vCPU | 2 GiB | $20/mo |
| 2 vCPU | 4 GiB | $40/mo |
| 4 vCPU | 8 GiB | $80/mo |
Postgres and Redis price their compute the same way, listed on their pages. Your plan sets the per-service CPU and memory ceilings.
The free unit is 0.5 vCPU / 1 GiB: your primary account runs one web service, one Postgres, and one Redis at that shape free, forever — see Free tier.
The free allowance is a price deduction, not a slot. Upsize a free web service and you pay price(service) − price(free unit) — the first 0.5 vCPU / 1 GiB stays free. On the Free plan today, resource ceilings cap at the allowance itself, so upsizing beyond the free unit requires a paid plan.
Locations
An app runs in one or more locations, and every service in the app runs in all of them. How many locations an app can span is set by your plan — see the plan comparison.
Adding or removing a location is a spec change like any other: Koo applies it and the app's status reflects the result.
What happens when you change a service
A service has two halves: the spec (what you asked for — size, environment, replicas, image) and the status (what is actually running). Changing a service means changing the spec:
- You edit the spec in the console or API.
- Koo records the change and applies it to Koo's hosting layer.
- The service's status updates to reflect observed reality — which version is running, how many replicas are ready — with a short lag. See Status.
Image changes additionally create a new deployment, so every version of your service stays addressable for rollback.