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

# Other platforms

> Deploy Compiler on Kubernetes, Amazon ECS or any other container platform.

Compiler ships as a single container image, so it runs on any platform that can run a container and give it PostgreSQL and Redis. This guide walks through deploying it on your own platform, such as Kubernetes, Amazon ECS, Nomad or Cloud Run.

The steps use your platform's usual building blocks. On Kubernetes, that's a Deployment, Service, Ingress and Secret. On ECS, it's a task definition and service behind an Application Load Balancer.

## Prerequisites

* A container platform that can pull public images from `ghcr.io`
* A domain or subdomain for Compiler, such as `compiler.yourdomain.com`, and a TLS certificate for it
* A way to provision PostgreSQL and Redis, either managed services or your own

## Step 1: Provision PostgreSQL and Redis

<AccordionGroup>
  <Accordion title="PostgreSQL 16 or later" icon="database" defaultOpen>
    Create an empty database that Compiler owns. Managed services such as Amazon RDS, Aurora PostgreSQL, Cloud SQL and Azure Database for PostgreSQL work.

    The database user must be able to create tables and the `pg_trgm` extension, which the first migration adds. On RDS, the master user can.
  </Accordion>

  <Accordion title="Redis 7 or later" icon="bolt" defaultOpen>
    Managed services such as Amazon ElastiCache and Memorystore work. Compiler refuses to start without Redis.
  </Accordion>
</AccordionGroup>

Note both connection strings for the next step. Use a `rediss://` URL when Redis requires TLS.

## Step 2: Create the secrets

Generate an encryption key for stored credentials:

```bash theme={null}
openssl rand -hex 32
```

Store these values in your platform's secret store, such as a Kubernetes Secret, AWS Secrets Manager or SSM Parameter Store:

| Secret | Value |
| - | - |
| `TOKEN_ENCRYPTION_KEY` | The key you just generated |
| `DATABASE_URL` | `postgresql://user:password@host:5432/compiler` |
| `REDIS_URL` | `redis://host:6379`, or `rediss://host:6379` for TLS |

<Warning>
  Back up `TOKEN_ENCRYPTION_KEY`. If it is lost, every stored credential (GitHub App key, AI provider keys, connectors) has to be entered again.
</Warning>

## Step 3: Run the container

Run one replica of the image with the secrets from step 2 and these settings:

| Setting | Value |
| - | - |
| Image | `ghcr.io/usecompiler/compiler:main` |
| Port | `3000` |
| Environment | `PORT=3000`, `PUBLIC_URL=https://compiler.yourdomain.com`, plus `DATABASE_SSL=true` if the database requires SSL |
| Volume | Mounted at `/repos` |

The image is public and built for `linux/amd64` and `linux/arm64`, so no registry credentials are needed. The other [environment variables](/reference/environment-variables) are optional.

<AccordionGroup>
  <Accordion title="Choosing an image tag">
    `main` is the latest build; pull it again to update. Every build also has a `sha-<commit>` tag. Use one to pin a version and roll back predictably. **Settings** in Compiler shows the commit your instance is running.
  </Accordion>

  <Accordion title="Why set PORT">
    Without `PORT`, the app uses 3000 when that port is free and picks another when it isn't. Setting it keeps the port your platform routes to fixed.
  </Accordion>

  <Accordion title="Choosing a volume for /repos">
    Compiler clones the repositories it reads into `/repos`. The contents can be lost safely: Compiler re-clones any missing repository the next time someone loads the app, and shows a loading screen until it's ready.

    Ephemeral storage, such as an `emptyDir` volume or ECS task storage, works. A persistent volume avoids re-cloning after every restart or deployment, which matters for large repositories. Size it for full clones of every repository in every project.
  </Accordion>
</AccordionGroup>

Database migrations run automatically when the container starts, so no separate migration job is needed.

## Step 4: Configure the deployment lifecycle

Keep to one replica, and make sure an old and a new one never run side by side. Each replica runs migrations on startup and keeps its own clones of your repositories.

When it receives `SIGTERM`, Compiler stops taking new work and gives in-progress answers up to 25 seconds to finish, so allow at least 30 seconds before the container is killed.

<Tabs>
  <Tab title="Kubernetes">
    * Set `replicas: 1` and `strategy.type: Recreate`
    * Set `terminationGracePeriodSeconds: 30` or more
  </Tab>

  <Tab title="Amazon ECS">
    * Set the service's desired count to `1`
    * Set the deployment's minimum healthy percent to `0` and maximum percent to `100`
    * Set the container's `stopTimeout` to `30` or more
  </Tab>
</Tabs>

## Step 5: Add health checks

`GET /up` on port 3000 returns `200 OK` when the app can reach its database, and `503` when it can't. Use it for liveness and readiness probes, and for load balancer target health checks.

Requests wait until startup migrations finish, so give the first check some room with an initial delay, a startup probe or an ECS health check grace period.

## Step 6: Expose it over HTTPS

The container serves plain HTTP. Put a load balancer, ingress or reverse proxy in front of it to terminate TLS, and point your domain at it.

* Route `https://compiler.yourdomain.com` to port 3000 on the container
* Pass the original `Host` header through. Compiler checks it against `PUBLIC_URL` for its MCP endpoint. Kubernetes ingress controllers and AWS load balancers do this by default
* Allow long-lived responses. Answers stream over HTTP, so raise any idle or read timeout below a few minutes

Compiler can run on a private network with no public address. The only exception is [Slack](/configuration/slack), which sends events to `/api/slack/events` and needs that path reachable from the internet.

## Step 7: Allow outbound access

If your network restricts egress, allow HTTPS (443) from the container to these hosts:

| Host | When | Purpose |
| - | - | - |
| `github.com` | Always | Clone and fetch repositories |
| `api.github.com` | Always | GitHub App authentication and repository data |
| `api.anthropic.com` | Anthropic API provider | Claude |
| `bedrock.<region>.amazonaws.com` | AWS Bedrock provider | Validate credentials and list models |
| `bedrock-runtime.<region>.amazonaws.com` | AWS Bedrock provider | Claude |
| `<bucket>.s3.<region>.amazonaws.com` | [Storage](/configuration/storage) is configured | File uploads |
| `slack.com` | [Slack](/configuration/slack) is connected | Replies and installation |

The container also needs to reach your database and Redis, any MCP connectors you add, and your identity provider if you use SSO.

## Step 8: Finish setup

Open `https://compiler.yourdomain.com` and sign up as the first user. Setup then walks you through:

1. Connecting a [GitHub App](/configuration/github-app) and choosing the repositories Compiler may read
2. Choosing an AI provider, either the Anthropic API or [AWS Bedrock](/configuration/aws-bedrock)
3. Creating your first project

<Note>
  On AWS, Bedrock and S3 storage take an IAM access key ID and secret access key, entered in the app. Compiler doesn't use instance profiles, ECS task roles or IAM Roles for Service Accounts (IRSA).
</Note>

## Updating

Pull the new image and restart the deployment. With the `main` tag, that's a rollout restart on Kubernetes or a forced new deployment on ECS. With a pinned `sha-` tag, change the tag. Migrations run on startup.

## Quick reference

| Requirement | Value |
| - | - |
| Image | `ghcr.io/usecompiler/compiler:main` |
| Port | `3000`, plain HTTP |
| Health check | `GET /up` |
| Database | PostgreSQL 16 or later, with `pg_trgm` |
| Cache | Redis 7 or later |
| Required env | `DATABASE_URL`, `REDIS_URL`, `TOKEN_ENCRYPTION_KEY`, `PUBLIC_URL`, `PORT` |
| Writable path | `/repos` |
| Replicas | 1, never two at once |
| Shutdown grace | At least 30 seconds |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.