Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
103 changes: 103 additions & 0 deletions apps/docs/src/content/docs/discover/default/en/getting-started.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,109 @@ You'll land in the **master** realm, the built-in realm that manages all other r
The default admin credentials are for local development only. Change them immediately in any non-local environment by setting the `ADMIN_USERNAME`, `ADMIN_PASSWORD`, and `ADMIN_EMAIL` environment variables.
:::

## Deploy Without Cloning the Repository

The quickstart above clones the repository, but you don't need the source code to run FerrisKey. The API, web app, and database migrations all ship as published images on `ghcr.io/ferriskey`. To deploy on a server, save the following as `docker-compose.yml` and start it directly — no checkout required:

```yaml title="docker-compose.yml"
services:
db:
image: postgres:18.2
environment:
POSTGRES_DB: ferriskey
POSTGRES_USER: ferriskey
POSTGRES_PASSWORD: ferriskey
volumes:
- pgdata:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -d ferriskey"]
interval: 10s
timeout: 10s
retries: 5
start_period: 30s

db-migrations:
image: ghcr.io/ferriskey/ferriskey-api
entrypoint: ["sqlx"]
command: ["migrate", "run", "--source", "/usr/local/src/ferriskey/migrations"]
environment:
DATABASE_URL: postgresql://ferriskey:ferriskey@db/ferriskey
restart: "no"
depends_on:
db:
condition: service_healthy

api:
image: ghcr.io/ferriskey/ferriskey-api
environment:
ALLOWED_ORIGINS: http://localhost:5555
WEBAPP_URL: http://localhost:5555
DATABASE_HOST: db
DATABASE_NAME: ferriskey
DATABASE_USER: ferriskey
DATABASE_PASSWORD: ferriskey
ports:
- 3333:3333
depends_on:
db-migrations:
condition: service_completed_successfully

webapp:
image: ghcr.io/ferriskey/ferriskey-webapp
environment:
API_URL: http://localhost:3333
ports:
- 5555:80

volumes:
pgdata:
name: ferriskey_pgdata
```

Then start the stack:

```bash
docker compose up -d
```

The migration files are baked into the `ferriskey-api` image (under `/usr/local/src/ferriskey/migrations`), so the `db-migrations` service applies the schema without any checked-out source. These are the same images the repository's `registry` profile uses, extracted into a self-contained file you can drop onto any host or convert to a Docker Swarm stack.

:::callout{variant="info" title="Pin a version for production"}
The images above track the latest tag. For reproducible deployments, pin an explicit tag — for example `ghcr.io/ferriskey/ferriskey-api:vX.Y.Z` — on both the `api` and `db-migrations` services so they always run the same binary and schema.
:::

## Upgrading FerrisKey

Schema changes ship inside the API image, so upgrading a running stack is "pull, migrate, restart":

::::step-group
:::step{title="Pull the new images"}
```bash
docker compose pull
```
:::

:::step{title="Apply new migrations"}
The `db-migrations` service runs `sqlx migrate run`, which only applies migrations that have not run yet — so it is safe to run on every upgrade:

```bash
docker compose up -d db-migrations
```
:::

:::step{title="Restart the application"}
Once migrations complete, recreate the API and web app on the new images:

```bash
docker compose up -d api webapp
```
:::
::::
Comment on lines +132 to +154

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add database backup recommendation before upgrade.

The upgrade workflow does not mention backing up the database before pulling new images and applying migrations. Database backups are a critical safety measure before any schema migration, as migrations can be irreversible and may encounter unexpected issues.

📋 Suggested addition of backup step

Consider adding a step before "Pull the new images":

:::step{title="Back up your database"}
Before upgrading, create a database backup:

\```bash
docker compose exec db pg_dump -U ferriskey ferriskey > backup-$(date +%Y%m%d-%H%M%S).sql
\```

Store this backup in a safe location. In case of migration issues, you can restore from this backup.
:::
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx` around
lines 132 - 154, Insert a new step titled "Back up your database" immediately
before the existing "Pull the new images" step that tells users to create and
offline backup of the database and store it in a safe location (mention using
the running DB container via docker compose exec and pg_dump as the method), and
note that this backup can be used to restore if migrations fail; keep the rest
of the flow (the "Pull the new images", "Apply new migrations" which runs
db-migrations -> sqlx migrate run, and "Restart the application" steps)
unchanged.


:::callout{variant="warning" title="Keep api and migrations on the same tag"}
Always pull the `api` and `db-migrations` services from the **same image tag**. Running a newer API against an older schema — or an older API against a newer schema — can fail at startup.
:::

## Create Your First Realm

A realm is an isolated tenant. Users, clients, roles, and credentials all live inside a realm.
Expand Down
Loading