# Browser Listener
Source: https://autodock.mintlify.app/browser/index
Capture browser logs, network requests, and screenshots for AI debugging
# Browser Listener
With Autodock, you can feed logs from any browser session into your agent. Ask your agent to compare
db, server and browser logs to get a full picture of how your app is running.
**Mike's notes:** At [CronRhino](https://cronrhino.io), I would regularly ask people on the sales
and marketing team to check out my work, and I needed a way to debug their sessions remotely. This
feature allowed me to get a complete picture of what's going on end-to-end.
## How It Works
The browser listener lets your AI agent capture real-time data from any browser session:
* **Console logs** - All `console.log`, `console.error`, `console.warn`, etc.
* **Network requests** - Every fetch/XHR request with method, URL, status, timing, and
request/response bodies
* **JavaScript errors** - Uncaught exceptions and unhandled promise rejections
* **Screenshots** - On-demand page captures
## Quick Start
1. Ask your agent to start a browser listener:
```
"Start a browser listener so I can debug my webapp"
```
2. Your agent will call `browser.listen` and give you a command to paste in your browser console:
```javascript theme={null}
fetch('https://autodock.io/b/xK9mZ2')
.then((r) => r.text())
.then(eval);
```
3. Paste the command in your browser's developer console (F12 or Cmd+Option+I)
4. You'll see `[autodock] Listening...` in your console - the listener is now active
5. Your agent can now poll for events and request screenshots
## MCP Tools
### browser.listen
Creates a new browser listener session.
**Parameters:**
* `ttlMinutes` (optional): Session timeout in minutes (5-60, default: 30)
**Returns:**
* `token`: 6-character session token
* `consoleCommand`: The command to paste in browser console
* `expiresAt`: When the session expires
### browser.poll
Retrieves captured browser events.
**Parameters:**
* `token`: The 6-character session token
* `limit` (optional): Maximum events to retrieve (1-100, default: 50)
* `sinceMinutes` (optional): Only return events from the last N minutes (1-60, default: 5)
**Returns:**
* Console logs, network requests, and errors with timestamps
* Screenshot URL if one was captured
* Session status
### browser.shot
Requests a screenshot from the browser.
**Parameters:**
* `token`: The 6-character session token
**Note:** Screenshots take 10-15 seconds to capture. Call `browser.poll` after waiting to retrieve
the screenshot URL.
### browser.stop
Stops a listener session and cleans up resources.
**Parameters:**
* `token`: The 6-character session token
## Example Session
```
User: There's a bug on my checkout page. Can you help debug?
Agent: I'll start a browser listener to capture what's happening.
[calls browser.listen]
Paste this in your browser console:
fetch('https://autodock.io/b/xK9mZ2').then(r=>r.text()).then(eval)
Let me know when you've done that and triggered the bug.
User: Done! I clicked "Place Order" and it failed.
Agent: [calls browser.poll]
I can see the issue:
[12:34:56] ERROR Cannot read property 'id' of undefined
[12:34:56] NET POST /api/orders -> 500 (142ms)
REQ: {"items":[]}
RES: {"error":"Cart is empty"}
The order is failing because the cart items array is empty when
you click Place Order. Let me check your cart state management...
```
## Stopping the Listener
From the browser console:
```javascript theme={null}
autodock.stop();
```
Or ask your agent to stop it, which will call `browser.stop`.
## Privacy & Security
* Sessions expire after 30 minutes by default (configurable up to 60 minutes)
* Sensitive data like passwords, tokens, and auth headers are automatically redacted
* Request/response bodies are truncated to 2000 characters
* Screenshots are stored temporarily (5 minutes) and then deleted
* Each session is isolated to the user who created it
# Dev Box
Source: https://autodock.mintlify.app/dev-box/index
What ships on every Autodock environment
# Dev Box
Every Autodock environment comes with a batteries-included dev box - modern tooling, language
runtimes, and observability all pre-configured and ready to use.
**Mike's tip:** This is the greatest hits of dev tooling - the rig I reach for whenever I hack on
any project. Everything's fine-tuned to be usable and observable via MCP with minimal fuss. No
setup, no config files to copy around, just SSH in and start building.
## What's Installed
### Language Runtimes (via mise)
Autodock uses [mise](https://mise.jdx.dev/) as the universal version manager. These runtimes are
pre-installed and ready to use:
| Runtime | Version | Command |
| --------- | ------- | ---------------- |
| Python | 3.11.9 | `python` |
| Node.js | LTS | `node`, `npm` |
| Go | 1.22.5 | `go` |
| Rust | stable | `rustc`, `cargo` |
| Terraform | 1.9.5 | `terraform` |
Need a different version? Use mise:
```bash theme={null}
mise use python@3.12 # Switch Python version
mise use node@20 # Switch Node version
```
### Package Managers
* **pnpm** - Fast Node.js package manager
* **uv** - Fast Python package manager
* **yarn** - Alternative Node.js package manager
### Modern CLI Tools
| Tool | Replaces | Description |
| -------- | -------- | ------------------------------ |
| `rg` | grep | Ripgrep - fast search |
| `fd` | find | Fast file finder |
| `bat` | cat | Syntax-highlighted cat |
| `eza` | ls | Modern ls with git integration |
| `fzf` | - | Fuzzy finder |
| `jq` | - | JSON processor |
| `yq` | - | YAML processor |
| `httpie` | curl | Human-friendly HTTP client |
| `btop` | top | Resource monitor |
| `procs` | ps | Modern process viewer |
### AI Tools
* **Claude Code** - Anthropic's CLI for Claude (`claude`)
* **aichat** - All-in-one LLM CLI
* **Ollama** - Local LLM runner
* **aider** - AI pair programmer
* **shell-gpt** - GPT in your terminal
### Infrastructure Tools
* **Docker** - Container runtime with Compose
* **kubectl** - Kubernetes CLI
* **helm** - Kubernetes package manager
* **gh** - GitHub CLI
## Observability Stack
Your environment includes a complete observability stack that captures logs from your applications
and Docker containers automatically.
### How It Works
```
┌─────────────────────────────────────────────────────────────┐
│ Your Dev Box │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ Your App │────▶│ /workspace/ │────▶│ Promtail │ │
│ │ (logs to │ │ logs/*.log │ │ (tailer) │ │
│ │ file) │ └──────────────┘ └──────┬──────┘ │
│ └──────────────┘ │ │
│ │ │
│ ┌──────────────┐ ┌──────────────┐ │ │
│ │ Your App │────▶│ OTel │────────────┤ │
│ │ (OTLP) │ │ Collector │ │ │
│ └──────────────┘ └──────────────┘ │ │
│ ▼ │
│ ┌──────────────┐ ┌─────────────┐ │
│ │ Docker │─────────────────────────▶│ Loki │ │
│ │ Containers │ (Loki logging driver) │ (storage) │ │
│ └──────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ env.observe │
│ (MCP query) │
└─────────────────────────────────────────────────────────────┘
```
* **Loki** - Log storage running on port 3100
* **Promtail** - Tails `/workspace/logs` and `/var/log`, ships to Loki
* **Docker Loki Driver** - All containers automatically ship logs (no config needed)
* **OpenTelemetry Collector** - Receives OTLP on ports 4317 (gRPC) and 4318 (HTTP), exports to Loki
### Querying Logs with `env.observe`
Ask your AI agent to check the logs:
```
"Check the server logs for any errors"
```
Your agent will call `env.observe` and query Loki:
```
Agent: I'll check your environment logs.
[calls env.observe]
Here's what I found in the last 5 minutes:
[14:23:45] ERROR [api] Failed to connect to database
[14:23:45] ERROR [api] Error: ECONNREFUSED 127.0.0.1:5432
[14:23:46] INFO [api] Retrying connection...
It looks like your database isn't running. Let me start it:
[calls env.run with "docker compose up -d postgres"]
```
### Log Sources
| Label | Description |
| --------------------------------------- | -------------------------------------- |
| `{job="autodock"}` | Application logs from /workspace/logs/ |
| `{job="docker"}` | All Docker container logs |
| `{job="docker", container_name="..."}` | Specific container by name |
| `{job="docker", compose_service="..."}` | Docker Compose service |
| `{exporter="OTLP"}` | Logs sent via OpenTelemetry |
| `{exporter="OTLP", service_name="..."}` | OTel logs from a specific service |
### Example: Debugging Docker Services
```
User: My Redis keeps dying and I don't know why.
Agent: Let me check the Docker logs for Redis.
[calls env.observe with query "{job=\"docker\", compose_service=\"redis\"}"]
Found the issue:
[10:45:23] WARNING Redis is configured to save RDB snapshots, but is
unable to persist on disk. Out of memory.
[10:45:24] ERROR Background save terminated with error
Your Redis container is running out of memory. You can either:
1. Increase the container memory limit in docker-compose.yml
2. Disable RDB persistence with "save ''" in redis.conf
```
### Writing Logs
Write your application logs to `/workspace/logs/` and they'll be automatically captured:
```bash theme={null}
# Redirect app output to a log file
npm run dev > /workspace/logs/app.log 2>&1 &
# Or use tee to see output and log it
npm run dev 2>&1 | tee /workspace/logs/app.log
```
Docker containers ship logs automatically - no configuration needed.
## OpenTelemetry Auto-Instrumentation
For frameworks that support OpenTelemetry (FastAPI, Celery, Express, etc.), your dev box is
pre-configured to receive OTLP telemetry and ship it to Loki.
### Environment Variables
These are set globally in `/etc/environment`:
```bash theme={null}
OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
OTEL_EXPORTER_OTLP_PROTOCOL="grpc"
OTEL_LOGS_EXPORTER="otlp"
OTEL_TRACES_EXPORTER="otlp"
OTEL_METRICS_EXPORTER="otlp"
```
### Suggested Prompts
Autodock will instruct agents to automatically instrument via OTel if they detect it's being used.
It may also prompt you to add it. If not, here are some prompts you can use:
* "Add OpenTelemetry auto-instrumentation to this FastAPI app"
* "Enable OTel logging for my Celery workers"
* "Instrument this Express server with OpenTelemetry"
* "Set up tracing for my Python application"
### Querying OTel Logs
OTel logs can be queried over MCP by using the `env.observe` tool. If SSH'd into the box, you can
also query directly:
```bash theme={null}
curl 'localhost:3100/loki/api/v1/query' \
--data-urlencode 'query={exporter="OTLP"}'
```
OTel logs include rich metadata like service name, trace IDs, and code location.
## API Keys for Headless Access
Need to use Autodock from CI/CD pipelines, scripts, or other automation? Create an API key for
headless MCP authentication.
### Creating an API Key
Ask your AI agent to create one:
```
"Create an API key for my CI pipeline"
```
Or call the tool directly:
```
Agent: [calls account.create_api_key with name="CI Pipeline"]
API key created successfully.
**IMPORTANT: Save this key now - it will not be shown again!**
Key: adk_abc123...
```
### Using the API Key
Add the Autodock MCP server with your API key:
```bash theme={null}
claude mcp add --transport http autodock https://api.autodock.dev/mcp \
--header "Authorization: Bearer adk_your_key_here"
```
### Managing Keys
| Tool | Description |
| ------------------------ | ---------------------------------- |
| `account.create_api_key` | Create a new API key |
| `account.list_api_keys` | List your keys (shows prefix only) |
| `account.revoke_api_key` | Revoke a key by ID |
## Inbound Email
Every Autodock environment can receive emails at `*@{slug}.autodock.io`. This is invaluable for
testing email-dependent flows without configuring external mail services.
**Mike's tip:** While I don't like to pick favorites, this is probably my favorite feature. It
helps testing auth, marketing, and all sorts of flows that rely on the venerable workhorse that is
email.
### How It Works
```
┌────────────────────────────────────────────────────────────────────────────────────┐
│ │
│ Internet ──▶ anything@happy-panda.autodock.io │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ AWS SES │ (inbound email) │
│ └────┬─────┘ │
│ │ SNS notification │
│ ▼ │
│ ┌──────────┐ │
│ │ Autodock │ (Vercel webhook) │
│ │ Webapp │ │
│ └────┬─────┘ │
│ │ HTTPS + Bearer token │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────────┐ │
│ │ Your Dev Box │ │
│ │ │ │
│ │ https://47982--happy-panda.autodock.io/email │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌──────────┐ │ │
│ │ │ Your App │ (listening on port 47982) │ │
│ │ └──────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────────────────┘
```
1. Send an email to `anything@{slug}.autodock.io`
2. AWS SES receives it and notifies the Autodock webhook via SNS
3. The webhook forwards to your environment with Bearer token authentication
4. Your app handles the email (using the pre-installed boilerplate or your own handler)
### Quick Start
A boilerplate email handler is pre-installed at `~/.autodock/email-server.js`. Start it with:
```bash theme={null}
node ~/.autodock/email-server.js
```
Or run in background:
```bash theme={null}
nohup node ~/.autodock/email-server.js > ~/email.log 2>&1 &
```
Get full setup instructions from your agent:
```
"How do I receive emails in my environment?"
```
### Authentication
Webhook requests include a Bearer token that's unique to your environment. The token is provisioned
when your environment is created and stored at `~/.autodock/email-webhook-secret`. The boilerplate
handler validates this automatically. If writing your own handler:
```javascript theme={null}
const fs = require('fs');
const expectedToken = fs
.readFileSync(process.env.HOME + '/.autodock/email-webhook-secret', 'utf8')
.trim();
app.post('/email', (req, res) => {
const auth = req.headers.authorization;
if (!auth || auth !== `Bearer ${expectedToken}`) {
return res.status(401).json({ error: 'Unauthorized' });
}
// Handle email...
});
```
### Webhook Payload
| Field | Type | Description |
| -------------- | --------- | ---------------------- |
| `from` | string | Sender email address |
| `to` | string\[] | Recipient addresses |
| `subject` | string | Email subject |
| `textBody` | string | Plain text body |
| `htmlBody` | string | HTML body (if present) |
| `messageId` | string | SES message ID |
| `timestamp` | string | ISO timestamp |
| `spamVerdict` | string | "PASS" or "FAIL" |
| `virusVerdict` | string | "PASS" or "FAIL" |
**Limits:** 150KB max email size (SES SNS limit). Large emails or attachments are truncated.
## GitHub Actions Runner
Every Autodock environment includes a pre-installed GitHub Actions runner. Turn any environment into
a self-hosted runner for your CI/CD pipelines.
**Mike's tip:** Autodock tests Autodock using the Autodock GitHub runner by using Autodock to spin
up a runner to test Autodock by using Autodock to spin up a runner in order to... well, you get
the idea. Don't worry, there's a terminating condition... maybe...
### Quick Start
1. Get a registration token from GitHub:
* Go to your repo → Settings → Actions → Runners → New self-hosted runner
* Copy the token (valid for 1 hour)
2. Ask your agent to configure the runner:
```
"Set up a GitHub runner for https://github.com/myorg/myrepo with token ABCD1234"
```
Your agent will call `env.gh_runner` and return the commands to configure and start the runner.
### How It Works
The runner is pre-installed at `/opt/actions-runner` and configured in **ephemeral mode** - it
processes one job and then exits. This is ideal for dynamic environments where you want clean state
for each job.
```yaml theme={null}
# In your workflow, target autodock runners
jobs:
build:
runs-on: [self-hosted, autodock, happy-panda] # Your env slug
steps:
- uses: actions/checkout@v4
- run: npm test
```
### Labels
Runners are automatically labeled with:
* `autodock` - All Autodock runners
* `{slug}` - Your specific environment (e.g., `happy-panda`)
* Any custom labels you specify
## For Kubernetes Workloads
If you're running Kubernetes with its own observability stack (Datadog, Grafana Cloud, etc.), you
can disable the built-in logging:
```bash theme={null}
# Stop the local observability stack
sudo systemctl stop promtail loki
# Disable on boot
sudo systemctl disable promtail loki
```
To use a different Docker logging driver:
```bash theme={null}
# Edit /etc/docker/daemon.json
sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
EOF
# Restart Docker
sudo systemctl restart docker
```
# GitHub App
Source: https://autodock.mintlify.app/github-app/index
Turn every PR into a command center for preview environments
# GitHub App
Autodock turns your GitHub PR page into a command center for a preview environment. From spinning up
environments to automated testing to leaving artifacts, the GitHub App makes sure your PR is on-spec
and bug-free while giving you full SSH access to the dev boxes that back these environments.
**No configuration required.** Install the app, and Autodock posts a comment on every PR with
options to spin up a preview. Claude analyzes your changes and handles the rest.
## Quick Start
1. **Install the GitHub App** at
[github.com/apps/autodock-preview](https://github.com/apps/autodock-preview)
2. **Link your account** - You'll be redirected to Autodock to connect the installation
3. **Open a PR** - Autodock automatically posts a comment with preview options
That's it. No YAML files, no secrets, no workflow configuration.
## How It Works
When you open a pull request:
1. Autodock analyzes your PR to determine if a preview environment would be helpful
2. If recommended, you click to spin up a preview environment
3. Claude Code clones your repo, installs dependencies, builds, and runs setup
4. The PR comment updates in real-time with progress and connection details
5. Push more commits and changes sync automatically
6. Close the PR and the environment is destroyed
## PR Comment States
The Autodock PR comment acts as a live dashboard for your preview environment. Here are all the
possible states you'll encounter:
### Setup Required
**When:** The GitHub App is installed but hasn't been linked to an Autodock account yet.
**What you see:** A message prompting you to complete setup by linking the installation to your
Autodock account. Once linked, preview environments will be created automatically for future PRs.
**Action:** Click the setup link and sign in or create an Autodock account.
***
### Analyzing
**When:** A PR is opened and Autodock is analyzing the changes.
**What you see:** Claude is reviewing the PR to determine if a preview environment would be helpful.
This typically takes a few seconds.
**Action:** Wait for analysis to complete.
***
### Not Recommended
**When:** Claude analyzed the PR and determined a preview isn't needed.
**What you see:** An explanation of why a preview isn't recommended (e.g., documentation-only
changes, config tweaks). A button to spin up a preview anyway if you want one.
**Action:** Click "Spin up environment" if you still want a preview.
***
### Trigger Posted
**When:** Claude recommends a preview and is waiting for you to trigger it.
**What you see:** A button to spin up the preview environment. Options for different setup modes.
**Action:** Click the button to start provisioning.
***
### Claiming Environment
**When:** Autodock is claiming a VM from the warm pool.
**What you see:** Progress indicators showing the setup stage. Once claimed, MCP and SSH connection
commands appear (you can connect immediately even while setup continues).
**Action:** Optionally connect early via MCP or SSH to watch setup in real-time.
***
### Cloning Repository
**When:** The environment is cloning your PR branch.
**What you see:** Progress indicator updated to show cloning is in progress. Connection info
available.
**Action:** Wait for cloning to complete, or connect to watch.
***
### Installing Dependencies
**When:** Claude is installing dependencies (npm install, pip install, etc.).
**What you see:** Progress indicator showing installation step. Connection info available.
**Action:** Wait for installation to complete.
***
### Building Project
**When:** Claude is building your project (next build, webpack, etc.).
**What you see:** Progress indicator showing build step. Connection info available.
**Action:** Wait for build to complete.
***
### Running Setup
**When:** Claude is running final setup (starting dev servers, exposing ports, etc.).
**What you see:** Progress indicator showing setup step. Connection info available.
**Action:** Wait for setup to complete.
***
### Ready
**When:** Your preview environment is fully operational.
**What you see:**
* Preview URL (if a web server is exposed)
* MCP connection command
* SSH access details
* Setup summary from Claude
* Instructions for running tests via `/autodock-test` comments
**Action:** Click the preview URL, connect via MCP, or run tests.
***
### Waiting for Secrets
**When:** Your project requires environment variables that weren't provided.
**What you see:**
* List of missing environment variables
* A curl command to upload your local `.env` files securely
* Instructions for running the upload command
**Action:** Run the provided curl command in your project directory. Setup continues automatically
after upload.
***
### Syncing
**When:** You pushed new commits and changes are syncing to the environment.
**What you see:** Progress indicator showing sync is in progress. Environment remains accessible.
**Action:** Wait for sync to complete. You can keep using the environment.
***
### Running Automated Tests
**When:** Automated tests are running against your preview.
**What you see:** A table with test checks (page load, console errors, network, auth test) showing
pending status.
**Action:** Wait for tests to complete.
***
### Automated Tests Complete
**When:** Automated tests have finished.
**What you see:**
* Test results table with pass/fail status
* Page load time
* Console error count
* Network failure count
* Auth test result
* Screenshots (if captured)
* Button to re-run tests
**Action:** Review results. Click re-run if needed.
***
### Running User Test
**When:** You triggered a test via `/autodock-test ` comment.
**What you see:**
* The test prompt you provided
* Live progress of test steps
* Status for each step (pending, running, passed, failed)
**Action:** Wait for the test to complete.
***
### User Test Complete
**When:** A user-triggered test has finished.
**What you see:**
* Test results with step-by-step breakdown
* Screenshots captured during the test
* Summary of what happened
* Previous test results (up to 3 runs)
* Button to re-run the last test
**Action:** Review results. Run additional tests as needed.
***
### Failed
**When:** Setup encountered an error and couldn't complete.
**What you see:**
* Error message explaining what went wrong
* Exit code (if applicable)
* Link to full session log
**Action:** Review the error and session log. Fix the issue and push a new commit, or use MCP/SSH to
debug manually.
***
### Destroyed
**When:** The environment has been destroyed (typically when PR is closed).
**What you see:** Confirmation that the environment is destroyed.
**Action:** No action needed. Open a new PR to get a new preview.
## Running Tests
Once your environment is ready, you can run tests by commenting on the PR:
```
/autodock-test Navigate to the homepage and verify it loads correctly
```
Claude will:
1. Open a browser in the environment
2. Execute the test steps you described
3. Capture screenshots at each step
4. Report results back in the PR comment
### Example Test Prompts
* `/autodock-test Test the login flow with valid credentials`
* `/autodock-test Click the sign up button and fill out the registration form`
* `/autodock-test Navigate to /dashboard and verify user data displays`
* `/autodock-test Add an item to the cart and proceed to checkout`
## Troubleshooting
**Environment is stuck provisioning**
Check the session log link in the PR comment. You can also connect via MCP or SSH to see what's
happening in real-time.
**Secrets aren't being recognized**
Make sure your `.env` files are in the project directory when you run the upload command. The script
searches for all `.env*` files.
**Preview URL returns 502**
Your dev server might not be running or might be bound to localhost. Autodock exposes ports bound to
`0.0.0.0`. Check if the server is running via SSH.
**GitHub App not posting comments**
Verify the app is installed for your repository and linked to an Autodock account. Check the
installation settings at
[github.com/settings/installations](https://github.com/settings/installations).
# Autodock
Source: https://autodock.mintlify.app/index
Cloud development environments that just work
## Welcome back!
> But wait, this is my first time using Autodock, why am I being welcomed back?
We missed you. In 1993, you or someone you know was using a simple, no-frills server for developing
software. Then the cloud came and created all sorts of logistical and financial barriers between you
and your staging environment.
Autodock takes you back to 1993. We give you a simple, affordable, instantly-reachable staging
environment where you can hack on and preview software.
As development has evolved slightly since 1993, we give you a few additional tools to make your
experience more pleasant.
1. We intelligently pause and restart your dev server to maximize cost efficiency.
2. Our environments' full history is observable via MCP, from logs to network calls to files.
3. Ports are permissive by default and linked to a human-readable URL.
4. We fill the dev box with a boatload of software you may find useful.
## Quickstart
Add Autodock's MCP server to your AI coding tool:
Click this link to auto-configure Cursor:
**Add Autodock to Cursor**
Run this command:
```bash theme={null}
claude mcp add --transport http autodock https://autodock.io/api/mcp/streamable-http
```
**Add Autodock to VS Code**
Add this URL as an HTTP MCP server in your AI tool:
```
https://autodock.io/api/mcp/streamable-http
```
Once connected, just ask your agent to spin up a dev server:
```
"Launch an Autodock environment for me"
```
From there, you can:
* Sync code from your local machine to the dev box
* Run commands remotely without leaving your agent
* Expose ports and share preview links with colleagues
* Debug with the built-in runner MCP and browser listener
## Autodock's story
My name is Mike, and I'm the founder and sole-employee of Autodock. In addition to hacking on
Autodock, I make my living doing several software development gigs.
I created Autodock because no one out there is selling a good staging environment.
I often need to spin up a preview of a PR with a frontend, backend, a DB, some storage, and some
secrets. All of the services that offer to do this "out of the box" don't really work. I found that
creating and ssh-ing into VMs, pulling my repo(s), and spinning up services was, on balance, faster.
Of course, this flow has its own set of issues. I started writing some scripts to overcome them, and
the scripts turned into a pile of golang, and a pile of golang turned into a company.
All of my clients love Autodock, and at a certain point, I started selling it to them. Nowadays, I
sell it to anyone who finds it useful. I'd be honored to earn your trust as a customer of Autodock.
## Getting Help
I personally answer all (legitimate) help requests. It doesn't matter what plan you're on. I'll help
you out. Just ping me on our [Discord server](https://discord.gg/autodock).
# MCP
Source: https://autodock.mintlify.app/mcp-server/index
Control Autodock environments from your favorite AI agent
Autodock allows you to spawn, connect to, and manage remote development servers by talking to your
favorite agents using MCP.
**Mike's tip:** When I use Autodock at [Rightware](https://rightware.com), I start a server using
MCP and leave it up during the day so that folks can test out features end-to-end as I hack on
them in real time.
## Quickstart
Add the Autodock MCP server to your favorite AI tool:
```bash theme={null}
claude mcp add --transport http autodock https://autodock.io/api/mcp/streamable-http
```
Click to install directly:
**→ Add to Cursor**
Or add manually to your Cursor MCP settings:
```json theme={null}
{
"mcpServers": {
"autodock": {
"url": "https://autodock.io/api/mcp/streamable-http"
}
}
}
```
**→ Add to VS Code**
Or add manually to your VS Code MCP settings:
```json theme={null}
{
"mcpServers": {
"autodock": {
"type": "http",
"url": "https://autodock.io/api/mcp/streamable-http"
}
}
}
```
```bash theme={null}
codex mcp add autodock --url https://autodock.io/api/mcp/streamable-http
```
Add this URL as an HTTP MCP server in your AI tool:
```
https://autodock.io/api/mcp/streamable-http
```
**Mike's tip:** This always trips me up. Once in your agent, you usually need to type `/mcp`, find
Autodock, and authorize it. After that, it's smooth sailing.
After installing Autodock, try the following commands with your agent:
1. Please spin up an autodock box.
2. Sync my work.
3. Run everything.
4. Expose ports.
That should get you up and running! For more advanced use cases, see the reference below.
## Tool Reference
### Environment Lifecycle
| Tool | Description |
| ------------- | ----------------------------------------------------------- |
| `env.launch` | Launch a new environment. Returns SSH credentials and URLs. |
| `env.list` | List all your environments with their status. |
| `env.status` | Get detailed status for a specific environment. |
| `env.stop` | Stop a running environment (can be resumed later). |
| `env.destroy` | Permanently destroy an environment. |
### File & Command Operations
| Tool | Description |
| ---------- | -------------------------------------------------- |
| `env.sync` | Get SSH credentials for syncing files (rsync/scp). |
| `env.run` | Get SSH command to execute commands remotely. |
### Port Exposure
| Tool | Description |
| ----------------- | ------------------------------------------ |
| `env.expose` | Expose a port with a public HTTPS URL. |
| `env.unexpose` | Remove an exposed port. |
| `env.listExposed` | List all exposed ports for an environment. |
### Reserved Instances
Reserved instances run 24/7 without auto-stopping and don't count against your concurrent
environment limit. A reserved instance costs \$149 and lasts for 30 days. Requires a paid plan
(Starter or Pro).
| Tool | Description |
| --------------------- | --------------------------------------------------------------------------------------- |
| `env.reserve` | Preview reservation cost for an environment. Shows price, duration, and current status. |
| `env.reserve_confirm` | Confirm and pay for reservation. Charges your card and reserves for 30 days. |
### Inbound Email
Receive emails at `*@{slug}.autodock.io` for testing auth flows, notifications, and more.
| Tool | Description |
| ----------- | ------------------------------------------------------ |
| `env.email` | Get your environment's email domain and webhook setup. |
### GitHub Actions Runner
Autodock environments include a pre-installed GitHub Actions runner at `/opt/actions-runner`.
| Tool | Description |
| --------------- | ------------------------------------------------------------ |
| `env.gh_runner` | Get commands to configure and start a GitHub Actions runner. |
The runner is configured in **ephemeral mode** - it processes one job and then exits. Labels
`autodock` and your environment slug are automatically added.
### Account & API Keys
| Tool | Description |
| ------------------------ | ------------------------------------------------------------------------------ |
| `account.info` | Get your plan, usage, quota status, and upgrade URL. Includes hours remaining. |
| `account.create_api_key` | Create an API key for headless MCP authentication. |
| `account.list_api_keys` | List your API keys (shows prefix only, not full key). |
| `account.revoke_api_key` | Revoke an API key by ID. |