Get started

Deploy Operate

Operate runs as a single Docker Compose stack on one machine. It connects to your systems through 60+ read-only integrations, spanning version control, logs, metrics, databases, cloud infrastructure, and more, to build a rich context layer around each incident. The more context Operate can gather, the sharper its root cause analysis. On top of that context layer it runs a three-agent pipeline, RCA → Verify → Resolve, that investigates production incidents and routes findings for human review.

• A machine (VM or bare metal) with Docker and Docker Compose installed. 32GB RAM runs roughly 8-10 concurrent cases; see Scaling below for sizing.
• An App ID from operatex.dev (step 1 below)
• Credentials for the integrations you want Operate to read from, such as source control, your log provider, and your application database (you enter these later, in the app)
• Outbound network access from the machine to your AI provider, your source control, and your observability stack

Every Operate instance requires an App ID, a unique identifier that authenticates your deployment to operatex.dev. It handles two things: usage billing, and provisioning the LLM Operate uses to run root cause analysis. Without it, Operate will not start.

Create an account

Sign up at operatex.dev/signup. Once you're logged in, navigate to the App IDs page and create a new App ID for this deployment.

Keep your App ID to hand, you will paste it into the onboarding wizard after deployment.

Operate runs the whole stack, web, worker, scheduler, MongoDB, and Redis, on one machine. Any VM or bare-metal host with Docker and Docker Compose installed works.

Size the machine to how many cases you expect to run at once. Each case needs roughly 1.5GB of RAM while it runs. A 32GB host comfortably runs 8-10 concurrent cases; 64GB runs 20-24. Cases beyond the limit wait in the queue and start as slots free, they never crash the machine. You can always move to a bigger host later.

Operate ships a production docker-compose.yml that wires the processes it needs: web (the UI and API on port 8080), worker (runs the investigations), beat (the scheduler), plus MongoDB and Redis backed by named Docker volumes. Web and worker share one local volume at /data/operate/host_repo where repositories are cloned, so on a single host there is nothing extra to configure for the workspace.

The four steps below take you from a fresh machine to a running Operate.

1. Get the compose file and env template

Operate is distributed as a Docker image, and the image bakes in its own docker-compose.yml and .env.example. Pull the image, then copy those two files out of it into your working directory:

# create a container from the published image (nothing runs), then copy the
# compose file and env template out of it, then clean up the container
cid=$(docker create jalantechnologies/operate:latest)
docker cp "$cid":/app/docker-compose.yml ./docker-compose.yml
docker cp "$cid":/app/.env.example ./.env.example
docker rm "$cid"

You now have docker-compose.yml and .env.example next to each other. To pin a specific release instead of the latest, swap :latest for a version tag (e.g. jalantechnologies/operate:0.83.0).

2. Create your .env

Copy the template to .env (Compose reads it automatically), then fill in the values. The only required values are the MongoDB credentials.

cp .env.example .env

Generate a strong password and use the same username and password in the two MongoDB variables and inside the connection URI:

openssl rand -hex 24   # use this as OPERATE_MONGODB_PASSWORD

# --- Required: MongoDB credentials for the bundled database ---
OPERATE_MONGODB_USERNAME=operate
OPERATE_MONGODB_PASSWORD=<the-generated-password>

# The URI must embed the SAME username and password as above. Keep the host
# (app-db) and options as-is to use the bundled MongoDB.
OPERATE_MONGODB_URI=mongodb://operate:<the-generated-password>@app-db:27017/operate?authSource=admin

# --- Optional ---
# Defaults to the bundled Redis; set only to use your own managed Redis.
# OPERATE_REDIS_URL=redis://redis:6379/0
# How many cases run in parallel on this host. Defaults to 2. Raise to match the machine.
# WORKER_CONCURRENCY=2

3. Start the stack

docker compose up -d

This starts every service. Give it a minute on the first run while MongoDB and Redis initialize.

4. Open Operate

Operate serves on port 8080. Open http://<your-host>:8080/operate in a browser. On a fresh install this lands on the getting-started page, where you create the admin account, enter your App ID, and connect your data sources (steps 4 and 5).

Bring your own managed MongoDB or Redis (optional)

To use a managed database instead of the bundled containers, point Operate at it in .env: set OPERATE_MONGODB_URI to your managed MongoDB connection string, and OPERATE_REDIS_URL to your managed Redis URL. Operate then uses those instead of the in-stack services, and you get the managed provider's own replication and backups.

Open Operate in your browser (http://<your-host>:8080/operate, or your HTTPS domain if you put a proxy in front). A fresh install boots straight to the getting-started page. The first person to sign up creates the admin account and is taken through setup. Nothing is collected at install time, you do it all here.

Step 1, App ID

Enter the App ID you created at operatex.dev. Click Verify to confirm it is valid, then Save & Continue.

Step 2, Public URL

The field is pre-filled from your browser's origin (e.g. https://your-domain.com). If Operate is behind a reverse proxy or CDN where the internal hostname differs from the external one, edit this to the external-facing URL. Click Save & Continue.

Steps 3–4, Log providers & Databases (skippable)

Configure your log provider (Datadog, CloudWatch, SolarWinds) and host app database connections. Both steps can be skipped and completed any time via Settings → Integrations. See Connect your data sources below for credentials and IAM requirements for each provider.

Step 5, Done

A summary shows what was configured and what was skipped. Click Enter Operate to reach the dashboard. Skipped steps can be completed later under Settings → Integrations.

All adapters are read-only. Operate never writes to your systems. Instead of opening PRs automatically, Operate generates a .patch file that your developers can review and apply manually. Log providers and database connections are configured during the wizard (step 4) or any time after via Settings → Integrations. Have your credentials ready before starting the wizard, the details for each provider are below.

Confirm everything is wired before routing real traffic.

1. 1Open Operate (http://<your-host>:8080/operate or your HTTPS domain)
2. 2Click the FAB (bottom-right) to open Admin Chat
3. 3Ask: "How many commits are on the main branch?"
4. 4Confirm the response shows real repo data with a tool call trace (actual git output)
5. 5A successful trace confirms the repo was cloned and the PAT is correctly configured

Everything runs on one host, so you scale by giving that host more capacity, in three ways, smallest first.

Raise worker concurrency

WORKER_CONCURRENCY sets how many cases one worker container runs in parallel. Raise it to use the RAM you have (each case needs about 1.5GB): roughly 8-10 on a 32GB machine, 20-24 on 64GB. Set it in your .env and restart.

WORKER_CONCURRENCY=8 docker compose up -d

Add more worker containers

Run several worker containers on the same host. They pull from the same queue and share the same workspace volume, so no extra wiring is needed.

docker compose up -d --scale worker=3

Use a bigger machine

When one host runs out of headroom, move the stack to a larger VM and raise concurrency to match. Cases over the current limit always wait in the queue and start as slots free, so a busy period queues rather than crashes.

Data durability

MongoDB and Redis write to named Docker volumes (mongodb-data and redis-data) declared in the compose file. Named volumes live outside the container lifecycle, so your cases, settings, stored credentials, and queued work survive container recreation, docker compose down and back up, image upgrades, and host reboots. You do not provision any storage yourself, Docker creates and manages these volumes on the host disk. Data is only lost if you explicitly remove the volumes with docker compose down -v or docker volume rm.

The repository workspace at /data/operate/host_repo (the repo-data volume) is rebuildable, Operate re-clones from source control whenever it needs to, so it does not need backups.