# crshdn/mission-control (Autensa): a self-hosted autonomous product engine

> Autensa is a Next.js and SQLite dashboard that drives OpenClaw agents through research, ideation, build and pull request. It is a serious self-hosting commitment, not a drop-in tool.

**crshdn/mission-control** — The world's first Autonomous Product Engine (APE): AI agents research your market, generate features, and ship code as PRs. Convoy mode, crash recovery, cost tracking, 80+ API endpoints. Self-hosted via OpenClaw Gateway.

- Repository: https://github.com/crshdn/mission-control
- Website: https://autensa.com
- Stars: 2,146 · Forks: 438
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/crshdn-mission-control

## What Autensa actually automates, and for whom

The repository describes itself as an Autonomous Product Engine: agents research a market, generate feature ideas, build them, test them, review the result and open a pull request. The pipeline named in the README runs Research, Ideation, Swipe, Build, Test, Review, Pull Request. The intended reader is not a solo developer looking for a code assistant. It is someone who already operates a product repository and wants a background loop that proposes and implements changes without a human starting each one.

The unit of work is a product, not a chat. Autensa stores products, tasks, agent assignments and sessions in a local SQLite database, and the dashboard is the control surface. A product can be set to Active or Paused, and the Danger Zone offers an Archive button that hides it from the dashboard while preserving its data. That vocabulary matters: the project assumes you will run several product lines through one instance and need to switch some off without deleting their history.

It is a poor fit for anyone who wants a hosted service. There is a live demo link in the README, but the product itself is designed around a self-hosted OpenClaw Gateway. The README recommends a Hetzner VPS, and the Dockerfile expects to own an /app/data volume and an /app/workspace volume. If you are not prepared to run that, the rest of the feature list is irrelevant to you.

## The OpenClaw gateway is the engine, Autensa is the cockpit

Autensa does not contain a model. It connects to an OpenClaw Gateway over a WebSocket and dispatches work to agents registered there. The default gateway URL is ws://127.0.0.1:18789, set through OPENCLAW_GATEWAY_URL, and remote connections require OPENCLAW_GATEWAY_TOKEN, which the .env.example suggests generating with openssl rand -hex 32. Model discovery has three modes: remote queries the gateway over RPC, local reads ~/.openclaw/openclaw.json, and auto tries remote, then local, then common defaults.

The dispatch path is where the recent releases are informative. In v2.5.0, each dispatched task gets its own OpenClaw conversation session. Before that, tasks on the same agent shared a session, so context accumulated until the model window was exhausted and the agent stalled. The openclaw_sessions table already carried a task_id column, and dispatch now uses it for session lookup and insert. If you are reading older write-ups about agents stalling under parallel load, this is the fix.

The same release loosened agent ID validation. Agent ID fields accept both standard UUID format and the 32-character hex identifiers the OpenClaw gateway emits; strict .uuid() validation previously rejected gateway IDs with an Invalid UUID error when imported agents were assigned to tasks. A v2.4.1 fix routes provider models through openclaw/default with the original model in the x-openclaw-model header, which addressed 404 errors on OpenClaw deployments. The picture is a project whose integration layer is still being corrected against real gateway behaviour, not a finished abstraction.

## Installing Autensa with Docker Compose on port 4000

The repository ships a Dockerfile and a docker-compose.yml, and the compose file is the shortest path. It builds the image locally from the Dockerfile, maps port 4000, reads an optional .env, and mounts two named volumes for the database and the agent workspace. The container runs as the node user, and the image declares a healthcheck that fetches http://127.0.0.1:4000/api/events every 30 seconds.

```yaml
services:
  mission-control:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "4000:4000"
    env_file:
      - path: .env
        required: false
    environment:
      NODE_ENV: production
      DATABASE_PATH: /app/data/mission-control.db
      WORKSPACE_BASE_PATH: /app/workspace
      PROJECTS_PATH: /app/workspace/projects
```

Before starting it, copy the example environment file and point it at your gateway. The compose file comments the host-machine case explicitly, because a gateway on the host is not reachable at 127.0.0.1 from inside the container.

```bash
cp .env.example .env
# then edit .env:
# OPENCLAW_GATEWAY_URL=ws://host.docker.internal:18789
# OPENCLAW_GATEWAY_TOKEN=<openssl rand -hex 32>
docker compose up -d --build
```

After the build finishes, the dashboard is at http://localhost:4000. The healthcheck hitting /api/events is the first thing to watch; if it never turns healthy, the app is up but the event stream is not, which usually means the gateway URL or token is wrong. For a bare-metal run instead, package.json defines npm run dev on port 4000 with Turbopack, npm run build, and npm run start, plus npm run db:seed to populate a fresh database.

## Repo Setup: the gate that stops agents opening doomed pull requests

The v2.5.1 release added a product-level Repo Setup tab, and it is the most consequential part of the current design. Before agents create PR-bound work, Autensa verifies authenticated git access, confirms the default branch, checks GitHub API and PR metadata access, GitHub Actions status, workflow token permissions, PR workflow secrets and PR workflow variables. Where the checks fail on supported GitHub configuration, the UI can set workflow token permissions to read/write, add missing Actions secrets and add missing Actions variables. Secret values are written directly to GitHub and the release notes state they are not stored in Autensa.

That last sentence is the design decision worth noticing. Autensa is willing to write to your GitHub repository configuration, but it refuses to become a secret store. The consequence is that the dashboard cannot show you a secret after you enter it, and a lost value has to be regenerated at the source.

The same release added a PR checks recovery panel to Build Queue tasks with GitHub pull requests. Failed checks are classified as retryable, repo setup, or external provider failures, with actions to rerun failed GitHub Actions jobs or rerequest external checks where GitHub supports it. Private repo readiness is handled separately: product creation and settings validate authenticated git access, detect the remote default branch, and require user confirmation before Autopilot starts. Workspace isolation preflights the selected branch and can use the detected default branch, which the release notes describe as avoiding main clone failures on repositories that use master. Anyone whose default branch is not main should read that line twice.

## Where Autensa gets in your way

The dependency on a running OpenClaw gateway is the first wall. There is no bundled model provider and no fallback path in the documented configuration; if the gateway is unreachable, the product loop has nothing to dispatch to. MODEL_DISCOVERY=auto softens discovery by falling back to local config and common defaults, but that is model listing, not execution.

The second wall is operational surface. The Dockerfile builds native modules, installing python3, make and g++ in the build stages for better-sqlite3, and the runtime image installs dumb-init. That is a normal Node deployment, but it is not a single static binary. The compose file runs with restart: unless-stopped, which means a misconfigured gateway token produces a container that keeps coming back and keeps failing its healthcheck.

The third is the nature of the output. Autensa opens pull requests. If your team has no review capacity, or if the repository has no CI that can meaningfully reject a bad change, the engine will simply produce a queue of PRs nobody reads. The Repo Setup checks reduce malformed PRs; they do not judge whether a generated feature is worth merging. There is also a real maintenance question: the last push to the repository was on 2026-07-07, and the most recent release listed is v2.5.1 from 2026-04-29. That is not an abandoned project, but it is also not a repository pushing daily, so treat the issue tracker as the place where gateway-version mismatches surface.

## Autensa against a plain agent runner

The obvious alternative is running an agent directly against a repository through a coding CLI or a CI-triggered agent job. The difference is where state lives. A CLI session is ephemeral: you invoke it, it edits files, it stops. Autensa keeps a SQLite database of products, tasks, sessions and dispatch history, exposes an event stream at /api/events, and reports 80+ API endpoints in the project description. That persistence is what makes Paused and Archived product states, per-task sessions, and a Build Queue with retry classification possible.

The cost of that persistence is the stack. A CLI agent needs a terminal. Autensa needs Node 20, a SQLite database on a mounted volume, a workspace directory, a gateway process, and a port. If your goal is one refactor on one repository, the CLI wins on every axis. If your goal is a standing loop that keeps proposing work across several products and you need to see which agent did what, the database is the reason to pay the hosting cost.

A second comparison point is the skill loop introduced in v2.4.0. Agents learn reusable procedures from completed tasks, Bayesian confidence scoring promotes proven skills, and matched skills are injected at dispatch as primary instructions. That is a different bet from prompt libraries maintained by hand: the instructions accumulate from the project's own history. Whether the promoted skills stay useful as the codebase moves is something only your own task history can answer.

## Licence, backups and the upgrade path

The repository is MIT licensed, which permits commercial use and modification with the usual requirement to keep the copyright and permission notice. The README and repository files do not state any additional restriction, and nothing in the repository suggests a separate commercial tier. This is a description of the licence text, not legal advice; if you are embedding Autensa in a product you sell, read LICENSE yourself.

Upgrades are a Docker rebuild, but the database is the part that needs care. package.json defines three scripts that matter here. npm run db:backup checkpoints the WAL and copies mission-control.db to mission-control.db.backup. npm run db:restore copies it back. npm run db:reset deletes the database and its WAL and SHM siblings and reseeds. The compose file keeps the database on the mission-control-data volume, so a rebuild does not erase it, but a schema change between releases would be the moment you want the backup file. The repository also lists PR-DATABASE-SAFETY.md and PRODUCTION_SETUP.md at the top level, which is where the project documents its own position on this.

A v2.4.1 fix is worth knowing before you upgrade: local agent role assignments are now preserved during gateway catalog sync instead of being overwritten every 60 seconds. If you are on an older build and your role assignments keep resetting, that is the bug.

## Conclusion

Adopt it if you already run an OpenClaw gateway, are comfortable with a Docker Compose stack on port 4000, and want agent-generated pull requests gated by the Repo Setup checks. Do not adopt it if you have no gateway, no repository you are willing to let agents open PRs against, or no appetite for a Node 20 image with a native SQLite build. Verify first that your gateway answers at OPENCLAW_GATEWAY_URL, that your default branch is detected correctly when it is not main, and that you have run npm run db:backup at least once.

## FAQ

### What is crshdn/mission-control for?

It is a self-hosted dashboard, branded Autensa, that runs AI agents through a product loop: market research, feature ideation, build, test, review and pull request. The README calls it an Autonomous Product Engine and it connects to an OpenClaw Gateway for model execution.

### How do I install crshdn/mission-control?

The repository ships a Dockerfile and docker-compose.yml. Copy .env.example to .env, set OPENCLAW_GATEWAY_URL and OPENCLAW_GATEWAY_TOKEN, then run docker compose up -d --build; the dashboard listens on port 4000.

### Does crshdn/mission-control work on macOS?

The documented install path is Docker Compose, so macOS works wherever Docker runs. The compose file notes that a gateway on the host machine is reached at ws://host.docker.internal:18789 rather than 127.0.0.1, and the README recommends a Hetzner VPS for running it.

### Can I turn off the automated research and ideation in crshdn/mission-control?

Yes. The product settings modal has a Status dropdown with Active and Paused, and the release notes state that paused products stop automated research and ideation cycles. A separate Archive button in the Danger Zone hides a product from the dashboard while preserving its data.

### How do I use crshdn/mission-control with a keyboard or mouse only?

The repository does not document keyboard shortcuts or mouse-only operation for the dashboard. Its documented controls are the product settings modal, the Repo Setup tab and the Build Queue panels.

## Sources

- [crshdn/mission-control on GitHub](https://github.com/crshdn/mission-control)
- [License: MIT](https://github.com/crshdn/mission-control/blob/main/LICENSE)
- [Project website](https://autensa.com)
- [README](https://github.com/crshdn/mission-control/blob/main/README.md)
- [Releases](https://github.com/crshdn/mission-control/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crshdn-mission-control