Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.replicas.dev/llms.txt

Use this file to discover all available pages before exploring further.

Configure what gets injected into workspaces from Settings → Environments in your dashboard. Each environment has its own tabs for Variables, Files, Skills, MCPs, Warm Hooks, and Warm Pool.
Everything below is also available through the Replica API. The Global environment can be addressed as global in any URL — no UUID lookup required.

​
Environments

An organization has one Global environment (applied to every workspace) plus any number of named environments. Each non-global environment optionally binds to a repository or a repository set as a property. Every variable, file, skill, and MCP belongs to a single environment. When a workspace runs in environment X, it receives Global merged underneath X. Values in X win on conflict. Each non-global environment can also carry an optional system prompt that is injected into the agent’s instructions when a workspace runs in that environment. Use it to pin a persona or domain focus (e.g., “You are a debugging specialist focused on observability.”) that should travel with every workspace bound to that environment.

​
Variables

Key-value environment variables injected into workspaces at boot.
  • Belong to a specific environment
  • Values are encrypted at rest
  • Paste .env-formatted blocks to batch add
  • Secrets can also be synced from Infisical or Doppler. Manual variables take priority over integration secrets

​
Files

Configuration files placed inside workspaces.
  • Place files at ~/... (home directory) or ~/workspaces/... (alongside cloned repos)
  • Belong to a specific environment
  • Max file size: 64 KB
  • Contents are encrypted at rest

​
Skills

Install skills from the skills.sh directory into your workspaces.
  • Belong to a specific environment
  • Search by name or slug to find available skills
  • Enable or disable per environment

​
MCPs

Configure MCP servers that workspaces can connect to.
  • Belong to a specific environment
  • Supported transports: stdio, http, sse. Codex sessions load stdio and streamable http MCPs. sse is Claude-only because Codex does not support that transport
  • Secrets in the config (env vars for stdio, headers for http and sse) are encrypted at rest
  • Distinct from the hosted Replicas MCP server, which exposes Replicas itself to your tooling

​
Attaching an environment to an automation

Each automation runs in exactly one environment, picked from the Environment dropdown in the automation editor. The environment supplies the repository (or repository set) the automation targets, plus everything Global doesn’t already cover. Pick the Global environment if the automation needs no extras beyond org-wide defaults. Otherwise pick the named environment whose repo / vars / MCPs / skills the automation should run with.

​
Slack and Linear intake

Slack and Linear intake also pick an environment for the workspace they create. The env’s binding determines which repository or repository set gets cloned. Org admins can set a default environment under Settings → Organization to skip the prompt.

​
Warm Hooks

Warm hooks are available on every plan.
Warm hooks run setup scripts ahead of time so workspaces provision instantly from a pre-warmed pool instead of waiting for dependency installs and builds on every boot.

​
The three levels

Warm hooks layer in a fixed order. Each level is optional, and any combination can be set.
#LevelWhere it livesApplies to
1GlobalWarm Hooks tab on the Global environmentEvery pre-warm in the org
2EnvironmentWarm Hooks tab on a named environmentPools for that environment
3RepositorywarmHook field in replicas.json / replicas.yaml at the repo rootWorkspaces that clone that repo
Levels 1 and 2 are configured in Settings → Environments. Level 3 is committed alongside the code.

​
Execution order

During pre-warming, the engine runs the hooks in this order, in the same workspace:
  1. Global warm hook
  2. Environment warm hook (skipped when the workspace runs in the Global env, since that’s already step 1)
  3. Repository warm hook(s) — one per cloned repo, alphabetical by repo name
Each step must exit 0 before the next runs; a failure stops the chain and marks the warmup failed. Within a single step, commands run sequentially and stop on the first non-zero exit. The repository step is itself a loop, so a failure in the alphabetically first repo aborts the remaining repos. Once pre-warming succeeds, the snapshot is added to the pool and the workspace’s startHook (from replicas.json / replicas.yaml) runs at assignment time.

​
When to use each level

  • Global — org-wide setup that every workspace needs (auth bootstrapping, shared CLI installs).
  • Environment — setup specific to one environment’s repo, vars, or persona (e.g., a staging-only build flag).
  • Repository — setup that belongs with the code: dependency installs, codegen, asset builds. Commit it so every environment that clones the repo gets the same prep for free.

​
Repository-level config

Add a warmHook field to your replicas.json or replicas.yaml: 
{
  "warmHook": {
    "timeout": 300000,
    "commands": [
      "npm install",
      "npm run build"
    ]
  },
  "startHook": {
    "timeout": 300000,
    "commands": [
      "npm run dev"
    ]
  }
}
timeout is per command in milliseconds (default 5 minutes, max 15 minutes). See Repository Configuration for the full file schema.

​
Warm pools

Warm pools keep pre-warmed workspaces ready per environment.
  • Default pool size is 5. Contact founders@replicas.dev to increase.
  • Replicas periodically reconciles pool levels.
  • Pools are automatically invalidated when an environment’s warm hook, variables, files, skills, MCPs, or system prompt change. Repository-level warmHook edits in replicas.json / replicas.yaml are picked up the next time a workspace warms; existing pre-warmed workspaces are not refreshed automatically.