> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asobeast.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Run a published release

> Every GitHub release publishes multi architecture API and web images to GitHub Container Registry. Releases before 1.0.0 have no latest tag.

Releases before `1.0.0` deliberately publish no `latest` tag, so every deployment names an explicit version. That prevents an unattended `docker pull` from moving a running instance onto a schema it has not been tested against.

## Which images are published?

Each GitHub release builds both applications for `linux/amd64` and `linux/arm64`, signs a build provenance attestation and pushes them to GitHub Container Registry.

| Image                           | Contents                                     |
| ------------------------------- | -------------------------------------------- |
| `ghcr.io/mradex77/asobeast-api` | NestJS API, queue workers, Prisma migrations |
| `ghcr.io/mradex77/asobeast-web` | Next.js dashboard and the same origin proxy  |

Four tag shapes are published for every release. Pick the narrowest one your upgrade policy allows.

| Tag shape | Example for release `v0.4.0` | Moves when                      |
| --------- | ---------------------------- | ------------------------------- |
| Version   | `0.4.0`                      | Never                           |
| Minor     | `0.4`                        | A patch release ships           |
| Major     | `0`                          | Any release in that major ships |
| Commit    | `sha-<commit>`               | Never                           |

## Run the stack

The sequence below creates the networks and volumes, starts PostgreSQL and Redis on an internal network, attaches the API to both networks and publishes only the web app.

```bash theme={null}
export ASOBEAST_IMAGE_TAG=0.4.0
export ASOBEAST_POSTGRES_PASSWORD="$(openssl rand -hex 32)"
export ASOBEAST_AUTH_SECRET="$(openssl rand -hex 32)"

docker network create --internal asobeast-backend
docker network create asobeast-frontend
docker volume create asobeast-pgdata
docker volume create asobeast-redisdata

docker run -d --name asobeast-postgres --restart unless-stopped \
  --network asobeast-backend \
  --volume asobeast-pgdata:/var/lib/postgresql \
  --env POSTGRES_USER=asobeast \
  --env POSTGRES_PASSWORD="$ASOBEAST_POSTGRES_PASSWORD" \
  --env POSTGRES_DB=asobeast \
  postgres:18-alpine

docker run -d --name asobeast-redis --restart unless-stopped \
  --network asobeast-backend \
  --volume asobeast-redisdata:/data \
  redis:8-alpine

docker run -d --name asobeast-api --restart unless-stopped \
  --network asobeast-backend \
  --env DATABASE_URL="postgresql://asobeast:$ASOBEAST_POSTGRES_PASSWORD@asobeast-postgres:5432/asobeast" \
  --env REDIS_HOST=asobeast-redis \
  --env REDIS_PORT=6379 \
  --env PORT=4000 \
  --env DEFAULT_COUNTRY=us \
  --env AUTH_SECRET="$ASOBEAST_AUTH_SECRET" \
  "ghcr.io/mradex77/asobeast-api:$ASOBEAST_IMAGE_TAG"

docker network connect asobeast-frontend asobeast-api

docker run -d --name asobeast-web --restart unless-stopped \
  --network asobeast-frontend \
  --publish 3000:3000 \
  --env API_INTERNAL_URL=http://asobeast-api:4000 \
  --env HOSTNAME=0.0.0.0 \
  "ghcr.io/mradex77/asobeast-web:$ASOBEAST_IMAGE_TAG"
```

The API image applies database migrations and seeds the default workspace when it starts. Add any optional API setting as a further `--env` flag on the API container.

## Why two networks?

Separating them is what keeps the datastores unreachable. `asobeast-backend` is created with `--internal`, so containers on it have no route off the host.

| Container           | `asobeast-backend` | `asobeast-frontend`          |
| ------------------- | ------------------ | ---------------------------- |
| `asobeast-postgres` | Yes                | No                           |
| `asobeast-redis`    | Yes                | No                           |
| `asobeast-api`      | Yes                | Yes, attached after creation |
| `asobeast-web`      | No                 | Yes                          |

The web container therefore reaches the API and nothing else, while PostgreSQL and Redis are reachable only from the API. This mirrors what `docker-compose.yml` does with its `frontend` and `backend` networks.

<Note>
  The checked in `docker-compose.yml` builds both images from source rather than pulling them. A supported pull based Compose file arrives with `1.0.0`. Until then, use the `docker run` sequence above when you want pinned images without a clone.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Self host with Docker Compose" icon="container" href="/install/docker-compose">
    The build from source path, with health checks and volumes handled for you.
  </Card>

  <Card title="Upgrade and roll back" icon="circle-arrow-up" href="/install/upgrade">
    Moving a pinned tag forward, and what to do when it goes wrong.
  </Card>
</CardGroup>