Requirements

Bearicorn is deployed from source with Docker Compose. The current deployment is a single-host stack: the application, PostgreSQL, and optional reverse proxy run on the same server.

Hardware

Start with:

Resource	Starting point	Why
CPU	2 vCPUs	The server builds the backend and web client during deployment.
Memory	4 GB	Leaves headroom for the image build, application, and PostgreSQL.
Disk	30 GB persistent storage	Holds the OS, Docker images, database, and stored attachments.

These values are conservative operator guidance, not tested capacity limits. Storage use depends on attachments and retention. Monitor CPU, memory, and disk rather than treating the table as a guarantee.

Supported deployment shape

• A Linux host with Docker Engine and Docker Compose v2.
• One local PostgreSQL container using the postgres_data named volume.
• One Bearicorn application container built from this repository.
• Caddy or Traefik on the same Docker host, or an existing HTTPS proxy in front of the Direct stack.

The repository does not currently provide supported Kubernetes, Cloud Run, managed-database, or multi-host deployment manifests.

Network

For the recommended Caddy stack:

• create a DNS A record for the hub;
• allow inbound TCP 80 and 443;
• restrict SSH to trusted source addresses or a provider access tunnel; and
• do not expose PostgreSQL port 5432 or application port 8080 publicly.

Caddy's public certificate flow requires the domain to resolve to the server and ports 80 and 443 to be externally reachable. See the Caddy HTTPS requirements.

Operator access

You need:

• SSH access with permission to install packages and manage Docker;
• git and openssl on the host;
• control of the domain's DNS; and
• a separate location for tested backups.

Membership in the Docker group grants root-equivalent control of the host. Limit it to trusted operators; Docker documents this in its Linux post-installation guide.

Availability

The provided Compose stacks are not highly available. A host, disk, or availability-zone failure can take the hub offline until it is restored. Use infrastructure snapshots as an additional recovery layer, but keep logical PostgreSQL backups as the primary portable backup.

Next step

Continue with the quick start or prepare a VM on AWS, Google Cloud, or DigitalOcean.