# 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

An **account** is both the billing tenant and the public identity people follow on the showcase — see [Your profile](/docs/showcase/your-profile) and [Teams & roles](/docs/collaboration/teams-and-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](/docs/apps/deploy-a-container). Deployments are immutable versions, so you can [roll back](/docs/apps/deployments-and-rollback) to a previous one.

Every resource has a stable, prefixed ID. The full object shapes are in the API reference: [Environment](/api/objects/environment), [Service](/api/objects/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](/docs/showcase/app-pages) 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](/docs/get-started/free-tier).

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:

- 
- 
-

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 |

Pick any CPU + memory (memory up to 8 GiB per vCPU).

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](/docs/get-started/free-tier).

> **Note:**
>
> 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](/docs/get-started/free-tier).

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:

1. 
2. 
3.

Image changes additionally create a new deployment, so every version of your service stays addressable for rollback.