---
sidebar_position: 1
title: Apps overview
---

# Managed Apps

Long-lived, per-tenant containers running open-source tools — each behind a stable HTTPS URL, on encrypted EFS, with an **autonomous agent-ops sidecar** that handles health checks, self-healing, and upgrades on its own.

```bash
zibby app templates              # browse the catalog
zibby app deploy grafana          # one-click — ECS service + EFS volume + ALB target group
zibby app logs <id> -t            # tail logs, SSE auto-reconnect
zibby app status <id>             # uptime, cost, version, agent-ops activity
```

## Two paths to a deployment

There are two ways to land a container on the apps fleet, and you pick by **whether the thing you want is in our catalog**:

| | **Catalog** | **Goal-mode** |
|---|---|---|
| Trigger | `zibby app deploy <slug>` | `zibby app deploy --goal "..."` |
| Source | Curated bundle (image + EFS layout + defaults) | Free-form natural-language install |
| Time-to-live | ~45-90 s | 2-15 min (Claude writes + runs the install script) |
| Licensing | Pre-cleared by Zibby | You direct the install; you accept the upstream license |
| Best for | Anything in the 22-app catalog | n8n, random GitHub project, anything not in the catalog |

Both paths land in the same shape — Fargate task, per-instance EFS volume, ALB target group, agent-ops sidecar — and look identical to every downstream `zibby app logs/status/upgrade` command. The only difference is **who wrote the install recipe**.

See [Goal-mode deploys](./goal-mode) for the long form.

## Why apps (not agents)

Both are pillars of Zibby Cloud. Pick by **how long the thing needs to run**:

| | **Agent** | **App** |
|---|---|---|
| Lifetime | Per-trigger (seconds to minutes) | Long-lived (24/7 or paused) |
| Surface | A graph of agent CLI calls | A whole open-source application |
| Billing | Per execution | Per minute, while running |
| Persistence | Session JSONL + S3 artifacts | Encrypted-at-rest EFS volume |
| Best for | "When ticket lands, classify it" | "Host Grafana for the team" |

If you find yourself wanting to **run an open-source web app behind a stable URL**, that's an App. If you want **agent-driven business logic that fires on events**, that's an [Agent](../recipes/).

## What you get with every app

- **Private subdomain** — `<instance-id>.apps.zibby.dev`, TLS by default
- **Dedicated EFS volume** — encrypted-at-rest, persists across container restarts and upgrades
- **Per-instance ALB target group** — your traffic doesn't share a load balancer with other tenants
- **Per-minute Fargate billing** — including the agent-ops sidecar, pause-to-stop billing
- **agent-ops sidecar** (see [Agent operator](./agent-ops)) — hourly health checks, self-healing, upgrades
- **SSE log streaming** — `zibby app logs -t` tails any container from anywhere
- **Optional auth proxy** — `--auth-type basic|token` puts a Caddy sidecar in front of the app (see [Auth proxy](./auth))
- **Dedicated egress IP addon** — pin outbound HTTPS through one whitelistable IP for self-hosted GitLab / Salesforce / Oracle Cloud

## The catalog

Each catalog entry is a curated bundle: container image, EFS volume layout, ALB wiring, secrets pattern, resource defaults. Today's catalog is **22 apps**. Run `zibby app templates` for the canonical, always-up-to-date list with live tier + hourly rate — the sample below is a snapshot, grouped by what each app is for.

### AI

| App | What it does |
|---|---|
| **Open WebUI** | ChatGPT-style UI for Ollama / OpenAI-compatible endpoints |
| **OpenHands** | AI software-engineer agent — drives the repo end-to-end, GitHub PR workflows |
| **Gas Town** | Multi-agent workspace — coordinate Claude, Codex, Cursor, Gemini |
| **Open Design** | Local-first design-artifact generator via your installed coding-agent CLIs |
| **Plane** | Self-hosted Jira / Linear alternative — issues, cycles, modules, pages |

### Automation

| App | What it does |
|---|---|
| **Activepieces** | Open-source Zapier alternative — visual automation, 400+ MCP servers |
| **ChangeDetection.io** | Watch any web page for changes — notifies on diff |
| **Gotify** | Self-hosted push-notification + webhook server |

### Data + APIs

| App | What it does |
|---|---|
| **PostgREST** | Serverless REST API on top of any Postgres schema |
| **Mathesar** | Spreadsheet-style web UI for Postgres |
| **PocketBase** | Single-file backend — SQLite + REST + realtime + auth + admin UI |

### Productivity + docs

| App | What it does |
|---|---|
| **Docmost** | Real-time collaborative wiki (multi-service: web + Postgres + Redis) |
| **SiYuan** | Privacy-first, block-based note-taking / PKM, local-first |
| **draw.io** | Client-side diagram editor (flowcharts, UML, ER, network) |
| **Glance** | Self-hosted homepage / dashboard with a feed of RSS, GitHub, monitors |
| **Homepage** | Self-hosted dashboard with service integrations + bookmarks |

### Observability

| App | What it does |
|---|---|
| **Grafana** | Dashboards for metrics, logs, traces |
| **OpenObserve** | Petabyte-scale logs + metrics + traces in one binary |
| **Uptime Kuma** | Self-hosted uptime monitor + status page |
| **Beszel** | Lightweight server monitor with historical charts |

### Identity

| App | What it does |
|---|---|
| **Authentik** | Self-hosted SSO / IdP (OAuth/SAML/LDAP) |
| **ZITADEL** | Cloud-native identity + access management (OAuth2/OIDC/SAML/LDAP) |

`zibby app templates` is the canonical, always-up-to-date list — the tables above are a snapshot, and the live command is the source of truth for each app's tier and hourly rate.

### Multi-service entries

A catalog entry can declare more than one container in the same task — useful for apps that need a DB + cache alongside the web tier. **Docmost** is the live example: web + `postgres:16-alpine` + `redis:7-alpine` sharing localhost and per-volume EFS access points. You don't have to think about it — `zibby app deploy docmost` reads identically — but `zibby app logs --service db` lets you scope log tails to one container.

### Not in the catalog? Use goal-mode

The catalog only includes apps whose licenses permit Zibby (a paid host) to ship them as a one-click bundle. Apps under the Sustainable Use License — most famously **n8n** — aren't in the catalog because the SUL forbids paid commercial hosting. They can still be deployed via goal-mode:

```bash
zibby app deploy --goal "Install n8n on port 5678 with sqlite persistence"
```

The customer (you) is directing the install — Zibby just provides compute. License terms of whatever you install are between you and the upstream project. See [Goal-mode deploys](./goal-mode).

## How tiers work

The catalog groups apps into three resource tiers:

| Tier | CPU | RAM | Rate |
|---|---|---|---|
| **Light** | 0.5 vCPU | 1 GB | $0.05/hr |
| **Standard** | 1 vCPU | 2 GB | $0.10/hr |
| **Heavy** | 2 vCPU | 4 GB | $0.25/hr |

Per-instance resource overrides are supported when you need to bump CPU / memory for one specific deployment without forking the catalog entry. See [Managing instances → resource overrides](./managing#resource-overrides). Goal-mode deploys default to 4 vCPU / 8 GB to give the install agent enough headroom.

## Pricing model

- **Per-minute Fargate billing** while the instance is running, scoped to the tier above
- **No flat platform fee** for apps — you pay only for what's running
- **Pause to stop the meter** — `zibby app destroy` immediately stops billing; redeploy when you need it back (data is gone after destroy; pause-without-destroy is on the roadmap)
- **Free tier**: $10 in credits on signup, enough to run a Light app for ~8 days

→ Next: [Deploy your first app](./deploy)