Skip to main content
Deploy Compiler to Heroku using container-based deployment. This guide covers dynos with ephemeral storage, where repositories are fetched on demand. For Kubernetes, ECS or another platform, see Other platforms.

Prerequisites

  • A Heroku account with container registry access
  • The Heroku CLI installed

How it works

Heroku dynos have ephemeral filesystems: any files written to disk are lost when the dyno restarts. This deployment configures Compiler to:
  1. Store repository metadata in Heroku Postgres (persistent)
  2. Clone repositories on demand to /tmp/repos (ephemeral)
  3. Automatically re-clone missing repositories when needed

Setup

1

Create a wrapper repository

Create a new repository with the following heroku.yml:
heroku.yml
And a Dockerfile that pulls the Compiler image:
Dockerfile
2

Create the Heroku app

3

Add Heroku Postgres

This sets the DATABASE_URL environment variable automatically. Heroku Postgres requires SSL, so enable it:
4

Add Redis

Redis is required: the app refuses to start without REDIS_URL. It holds resumable stream state so a client can reconnect to an in-progress response.
5

Configure environment variables

6

Deploy

Environment variables

The AI provider (Anthropic API or AWS Bedrock) and GitHub App credentials are configured through the onboarding flow, not as environment variables.

Behavior on dyno restart

When a Heroku dyno restarts:
  1. All cloned repositories in /tmp/repos are lost
  2. Repository metadata remains in Heroku Postgres
  3. The server starts immediately
  4. When a user loads the app, a sync gate detects missing repositories and triggers re-cloning
  5. The user sees a loading screen until their repositories are ready

Performance considerations

On eco dynos, the app sleeps after 30 minutes of inactivity. Waking up triggers a full restart, so repositories are re-cloned on the first page load.

Updating

If the upstream Dockerfile changed, pull it first, then push:
Or rebuild with the latest base image: