> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Devin environment setup
> Configure Devin's environment so sessions start with repos, tools, dependencies, environment variables, and secrets ready.
## What is Devin's environment?
Devin's environment is the workspace where Devin operates: a Linux-based virtual machine with your repositories cloned, tools installed, dependencies resolved, environment variables set, and configuration applied. It's the equivalent of a developer's laptop: the OS, the terminal, the installed toolchain, the cloned repos, and the credentials and settings those tools need.
Your environment configuration is saved as a **snapshot**: a frozen, bootable image that every session starts from. Configure it once, and every session boots into that known-good state.
## Why environment configuration matters
Devin works the same way any developer does: it clones repos, installs dependencies, runs lint, compiles code, and executes tests. To do any of that, it needs a working environment. Without one, Devin can't build your project, can't run your tests, and can't verify its own work. It would be like hiring a developer and not giving them a laptop.
Environment configuration gives Devin the tools, runtimes, credentials, environment variables, and project knowledge it needs to be productive from the first session. It also makes sessions faster: your snapshot already has repos cloned and dependencies installed, so Devin boots straight into productive work instead of setting up from scratch every time.
**This is the single highest-leverage thing you can do to improve Devin's effectiveness on your codebase.**
## How sessions work
Every session boots from a **snapshot**, a frozen, bootable image of the environment.
1. **Snapshot**: A pre-built image containing your repos, tools, and dependencies. Prepared in advance through configuration.
2. **Session**: Devin boots a fresh copy of the snapshot. Every session starts from the same clean state. Session changes don't persist back to the snapshot.
When your configuration changes, a new snapshot is built automatically. Each organization has exactly one active snapshot. Every session in that org boots from the same snapshot.
## Before you start
Before configuring Devin's environment, make sure Devin can access your repositories:
1. **Connect your SCM provider.** Go to **Settings > Connections** and connect GitHub, GitLab, Bitbucket, or Azure DevOps. Select which repositories Devin can access during setup. See the [integration guides](/integrations/overview) for detailed instructions.
That's it. Once connected, you can proceed to environment configuration.
1. **Connect your SCM provider (enterprise admin).** Go to **Enterprise Settings > Integrations** and connect your SCM provider. See [Git Integrations](/enterprise/integrations/git-integrations) for setup instructions.
2. **Grant each org access to its repos (enterprise admin).** Go to **Enterprise Settings > Repository Permissions** and assign repositories to each organization. Orgs cannot see or use repos until you explicitly grant access. See [Repository Permissions](/enterprise/integrations/git-integrations#repository-permissions).
3. **Configure the environment (org admin).** Once an org has repo access, proceed to environment configuration below.
If you skip these steps, repos won't appear when you try to add them to your environment. Devin needs repository access through your Git integration before it can clone and build.
## Set it up by asking Devin
This is the simplest way to configure Devin's environment and works for most repositories.
Start a Devin session and ask:
*"Set up your environment for this repo."*
Devin inspects your codebase and figures out which tools, runtimes, and dependencies it needs.
Devin proposes a blueprint as suggestion cards in the timeline. Review the proposed setup and approve the cards you want to use.
Devin runs a build from the approved blueprint and produces the snapshot that every session boots from.
For the full walkthrough, see [Let Devin do it](/onboard-devin/environment/blueprints#getting-started).
## Environment variables and secrets
Environment variables are part of your blueprint. Define non-sensitive values in a step's `env` field or write shared values to `$ENVRC`; see the [environment templates](/onboard-devin/environment/templates) for the `$ENVRC` and direnv patterns. Devin can infer tools and dependencies from your repository, but it cannot discover your credentials.
Store sensitive values as encrypted [Secrets](/product-guides/secrets) in the blueprint editor's **Secrets** tab, then reference them as `$VARIABLE_NAME`. Secrets are injected as environment variables during builds and sessions; see the [blueprint secrets guide](/onboard-devin/environment/blueprints#secrets) and [environment variables and secrets reference](/onboard-devin/environment/blueprint-reference#environment-variables-and-secrets).
## Choose your approach
Asking Devin is the default. If you want to author the configuration yourself, use [declarative configuration](/onboard-devin/environment/blueprints), the recommended manual path. Blueprints describe your environment, and builds automatically produce snapshots.
**Recommended manual path.** Review or edit the YAML Devin generates to control what gets installed, how dependencies are set up, and what Devin should know.
* Version controlled
* Auto-updating
* Composable across tiers
* Reproducible
## Related pages
Full field specification for blueprints: sections, GitHub Actions support, env vars, file attachments.
Copy-paste blueprints for Python, Node.js, Go, Java, Ruby, Rust, and advanced patterns.
Enterprise-wide environment management: 3-tier hierarchy, secrets, and cross-org configuration.