Development environment
Configure where your AI agents run and how your app previews work.

The development environment is where your AI agents write and test code. Think of it as a cloud-based dev machine that Superconductor spins up for each project. Your agents clone your repos, install dependencies, and run your app—all in this environment.
If you run into any issues during dev environment setup, reach out to us—our team would be happy to get on a call and walk you through the setup for your specific project or to answer questions over email.
Do I need to set up a dev environment?
You can start using Superconductor right away without configuring a development environment. Here's what works and what doesn't:
| Feature | Without dev environment | With dev environment |
|---|---|---|
| Agents update code | ✅ Yes | ✅ Yes |
| Agents commit and push to GitHub | ✅ Yes | ✅ Yes |
| Live app previews | ❌ No | ✅ Yes |
| Agents run tests | ⚠️ Limited | ✅ Yes |
| Agents run build scripts | ⚠️ Limited | ✅ Yes |
Without a configured environment, agents can still read and write code, but they won't be able to run your app or see it in action. For most projects, you'll want to set this up.
Assisted Environment Setup

When you create a new project, Superconductor automatically kicks off Assisted Environment Setup. An AI agent analyzes your repo, figures out what packages, build commands, startup commands, and services your project needs, and suggests a complete configuration for you. If you're happy with the agent's proposed commands, add them to your project with a single click, and you're all set.
Getting to the setup page
Assisted Environment Setup starts automatically when you create a project, but the agent runs in the background. To see its progress, review the suggestions, and confirm the commands, you need to open the setup page.
The fastest way: click Set up environment in the onboarding checklist on your project dashboard.

You can also get there from Project Settings by clicking Automatic setup in the Development Environment section.
How it works
- When you create a project (or click Automatic setup in Project Settings), Superconductor spins up a cloud instance and runs an agent that reads your repo's code, docs, and config files.
- The agent suggests a full environment configuration: packages, build commands, startup commands, secrets, and HTTP services.
- You review the suggestions in a three-pane UI:
- Chat (left): Talk to the agent, ask questions, or request changes
- Terminal (middle): A live terminal connected to the cloud instance
- Environment (right): The agent's suggested configuration, rendered in a readable format
- If the agent identifies secrets your project needs (API keys, database URLs, etc.), it'll prompt you to provide the values through a form in the chat. The agent can detect which secrets are needed but can't guess the values—you'll need to fill them in before applying the configuration.

- When you're happy with the configuration, click Apply to Project to save it.
After you apply, Superconductor builds an environment snapshot using your configuration. Once the build succeeds, agents can start working on tickets with full access to your running app, and you'll be able to use live previews.
Which agent runs the setup?
Assisted Environment Setup uses Claude Code (Opus 4.6) to analyze your repo and generate the configuration.
It uses your Anthropic credentials with this priority:
- Connected Claude account (OAuth) — used first if you've connected your Claude Pro or Max account
- Anthropic API key — used as a fallback if no connected account is available
The agent checks for valid credentials before doing any work. If neither a connected account nor an API key is configured, the setup will fail immediately with a clear error. Make sure you've added your Anthropic credentials during workspace setup before creating a project.
What the agent looks for
The agent reads your repo to determine:
- Packages: Which language runtimes you need (Node.js, Python, Ruby, Docker)
- Build commands: How to install dependencies, set up databases, and build assets
- Startup commands: How to start your dev servers
- Secrets: Which environment variables need sensitive values (API keys, tokens, etc.)
- HTTP services: Which ports your app listens on, for live previews
It prioritizes existing setup scripts (like bin/setup, bin/dev, or Makefile targets) over reinventing the wheel. If your project uses Docker for development, it'll configure Docker-based commands.
Editing your environment after setup

Once you've applied the agent's suggestions, you can make further changes at any time:
- Manual edits: Click Manual setup in the Development Environment section of Project Settings to open the manual configuration page, where you can edit commands, packages, secrets, and services directly.
- Re-run assisted setup: Click Automatic setup in Project Settings to start a fresh assisted setup session.
Older projects: If your project was created before Assisted Environment Setup was available, it won't have run automatically. If your project already has a configured environment, you'll see an Automatic setup button in the Development Environment section of Project Settings. If your project doesn't have a configured environment yet, you'll see a Configure button that takes you to manual configuration.
Manual configuration
You can also configure your dev environment by hand. This gives you full control over every setting.
Getting to the settings
There are a few ways to reach the manual configuration page:
- After assisted setup: Once you've applied the agent's suggestions (or if your environment is already configured), a Manual setup button appears in the Development Environment section of Project Settings.
- From the assisted setup page: Click Environment at the top of the assisted setup page to go directly to manual configuration.
- Older projects: Projects created before Assisted Environment Setup was available may show a Configure button in the Development Environment section of Project Settings, which links directly to manual configuration.
The manual configuration page has two main sections: Build (one-time setup) and Startup (runs each time).

Build settings
These settings determine how your environment snapshot is built. Changes here require rebuilding your environment.
Resources
Configure the compute resources for your environment:
- CPU: 2-8 cores
- Memory: 1-12 GB RAM
- Disk: 5-20 GB storage
Start with the defaults (2 CPU, 4 GB RAM, 10 GB disk) and bump them up if your builds are slow or running out of memory.
Packages
Select which language runtimes to install:
- Docker: Enable if your project needs containerization
- Node.js: Pick your version (20, 22, 24)
- Python: Pick your version (3.10, 3.11, 3.12, 3.13, 3.14)
- Ruby: Pick your version (3.2, 3.3, 3.4)
Only enable what you need—more packages mean longer startup times.
Secrets
Store sensitive values like API keys securely. Use them in your commands with the {{ secrets.SECRET_NAME }} syntax.
Example:
export API_KEY={{ secrets.MY_API_KEY }}Each secret has an Export to Environment toggle. When enabled, the secret is automatically available as an environment variable ($SECRET_NAME) across all build commands, startup commands, and terminal sessions — no manual export needed. Exported secrets are shown with an "exported" badge in the development environment settings.
Secrets are encrypted and redacted from build logs.
Build commands
Commands that run once when building your environment snapshot. Use these for:
- Installing dependencies (
npm install,bundle install) - Setting up databases
- Building assets
- Any one-time setup
Important things to know:
- Each command block runs in its own shell. Exports like
export API_KEY={{ secrets.API_KEY }}are only available within that block. cdinto your repo directory first—repos are cloned to/workspace/<repo-name>- To make environment variables available across command blocks and for running agents, enable Export to Environment on the secret. It will be exposed as
$SECRET_NAME.
Example build commands for a Node.js app:
cd /workspace/my-app
npm install
npm run buildExample for a Rails app:
cd /workspace/my-rails-app
bundle install
rails db:setupStartup settings
These settings run every time an agent starts working on your project.
Startup commands
Commands that start your development servers. The last command is automatically run in the background.
Each startup command block runs in its own shell. Secrets with Export to Environment enabled are available as $SECRET_NAME across startup command blocks.
Example for a Node.js app:
cd /workspace/my-app
npm run devExample for a Rails app:
cd /workspace/my-rails-app
bin/devHTTP services
Tell Superconductor which ports your app uses so we can create live previews.
| Field | Description |
|---|---|
| Name | A label for the service (e.g., web, api, vite) |
| Port | The port your service runs on (e.g., 3000, 8080) |
| Primary | Check this for the main service to show in App Preview. Only one service can be primary—this is what loads in the preview pane by default. Other services can also be previewed using the dropdown menu in the preview pane header. |
These are the default ports for common frameworks:
| App type | Service name | Port |
|---|---|---|
| Node/Vite | web | 3000 or 5173 |
| Rails | rails | 3000 |
| Django | web | 8000 |
| Next.js | web | 3000 |
We automatically create environment variables for each service. The pattern is AGENT_{SERVICE_NAME}_HOST, where the service name is uppercased and hyphens become underscores:
AGENT_WEB_HOSTfor a service named "web"AGENT_API_HOSTfor a service named "api"AGENT_MY_APP_HOSTfor a service named "my-app"
These variables contain the hostname of your live preview URL. Use them in your startup commands if your app needs to know its external URL at runtime—for example, to configure CORS, set callback URLs, or generate absolute links.
cd /workspace/my-app
export BASE_URL=https://$AGENT_WEB_HOST
npm run devYou can also write them to a .env.local file from your startup commands:
cd /workspace/my-app
echo "BASE_URL=https://$AGENT_WEB_HOST" > .env.local
npm run devBuilding your environment
After configuring your settings, click Save Development Environment. This triggers a build.
Tracking build progress
Watch the build log in the Terminal pane on the right side of the Dev Environment Edit page or at the top of the Dev Environment Edit page. You'll see:
- Starting - Environment is spinning up
- Running - Each command executes with a spinner
- Finalizing - Snapshot is being saved
What success looks like
When the build completes successfully, you'll see a green checkmark at the top of the Dev Environment Edit page and the message:
"Development environment built successfully!"

Once built, agents can start working on tickets immediately.
What a running preview looks like
When you launch a new implementation, your startup commands automatically run. Once they complete, your live preview loads.
You can see the live App Preview above the terminal:

Troubleshooting
Build command failures
If a build command fails, you'll see the error in the terminal pane with:
- The command that failed
- Exit code
- STDOUT and STDERR output
To fix:
- Update your build commands in Settings
- Click Rebuild Development Environment (or Save Development Environment if you made changes)
Common issues:
- Missing dependencies: Make sure you're installing everything your app needs
- Wrong directory: Remember to
cd /workspace/<repo-name>first - Missing secrets: Check that all required secrets are configured
Startup command issues
Startup commands run each time an agent starts. The preview loading screen shows each command's progress and output in real time, making it easy to spot failures.
If a command shows a red "Timed out" indicator, it exceeded the 90-second timeout. Try simplifying the command or splitting it into smaller steps.
For further debugging:
- Go to any Ticket Implementation in your project
- Click Show Terminal to run the startup commands manually
- Look for errors in the output
Common issues:
- Port already in use: Make sure you're not trying to start multiple servers on the same port
- Wrong port in HTTP services: Double-check the port matches what your app actually uses
- App crashing on startup: Check the command output on the loading screen or in the terminal
- Command timeout: A startup command took longer than 90 seconds. Consider optimizing or splitting it.
Previews not loading
See Preview not loading? in the Live Preview docs for troubleshooting steps.
Tips for success
- Start simple: Get a basic build working before adding complexity
- Test locally first: Make sure your setup commands work on your own machine
- Use the terminal: It's your best friend for debugging
- Check the logs: The terminal shows exactly what's happening
- One thing at a time: Add commands incrementally and rebuild to verify each step
Need help?
If you're stuck, reach out to us. Our team would be happy to get on a call and walk you through the setup for your specific project or to answer questions over email. Include:
- Your project name
- What you're trying to do
- Any error messages you're seeing