Environment prerequisites
Check access, connect source control, and configure runtime secrets before using Environments.
Check access and compute policy
Environments must be enabled for your organization in the hosted Factory experience. If Settings → Environments is missing, contact a manager or owner, or support@factory.com, to check access. A local-only or air-gapped installation does not provide this hosted surface.
Factory-hosted instances require an active paid subscription and an allowed compute policy. Free accounts cannot launch Environment sessions; trial, ended, or overdue subscription states can also block managed compute. Factory-hosted compute is currently unavailable for organizations in the EU region.
Your organization can restrict Environments to creating persistent Droid Computers. In that case, Environments may be visible in settings but absent from new-session and automation run pickers. Use the Droid Computer creation wizard in Settings → Droid Computers → Create to select a Ready Environment when its selector is available, or ask a manager or owner about your organization's access.
Managers and owners can create, edit, delete, and set defaults for organization Environments. Members can manage their own personal Environments and use organization Environments whose repositories they can access. Settings → Fleet is available to managers and owners.
Configured OpenCompute sources use your organization's infrastructure and provider policy. Their availability and capacity can differ from Factory-hosted compute.
Connect GitHub in both places
For repository-backed GitHub Environments, connect GitHub both personally and for your organization. One connection does not replace the other. The GitHub App must also have access to every repository the Environment uses.
- 1Open Settings → Account → General and connect your personal GitHub account under Code providers.
- 2Ask a manager or owner to open Settings → Organization and connect the organization's GitHub integration.
- 3In the GitHub App installation, grant access to the required repositories. If the installation uses selected repositories, add each repository explicitly.
- 4Confirm that your personal GitHub account can access those repositories, then return to Settings → Environments.
The organization integration supplies repository access for building; your personal connection verifies which repositories and Environments you can use. An organization Environment does not grant members access to its code. A member needs access to every included repository.
If the repository picker is empty or an Environment is missing, check all three: personal connection, organization connection, and GitHub App repository grants. You can create an Environment without repositories, but that does not fix repository access.
GitLab integrations and configured self-hosted source control are also supported. Other providers appear only when enabled for your organization. Use the repositories actually available in the picker rather than assuming every provider is enabled.
Configure runtime secrets
Environment instances use the managed-computer secrets in Settings → Account → Secrets. These values become environment variables at runtime; there are no per-Environment variable or secret fields in the Environment editor.
- 1Open Settings → Account → Secrets.
- 2Choose Personal, or Organization if you are a manager or owner adding shared values.
- 3Click Add secret. Enter a Secret name, such as
PACKAGE_TOKEN, and its Secret value, then save. - 4To rotate a value later, use Edit from its menu. Saved values cannot be viewed again.
Names use uppercase letters, numbers, and underscores, starting with a letter or underscore. Runtime-reserved names are not allowed. Values must be nonempty and single-line.
Organization secrets apply to managed computers for members and service accounts. Personal secrets apply to your computers in that organization. A personal secret overrides an organization secret with the same name. A delegation or automation running as a service account uses that account's secrets and the organization's defaults, not the configuring user's personal secrets.
New instances receive current values. Existing computers keep their current environment until credentials are refreshed and the relevant processes are restarted; changing a secret does not update a running process immediately. Deleting a personal override lets the organization value apply after refresh and restart.
Runtime secrets are not available during the Environment build. Setup scripts cannot use these values to authenticate to private package registries, artifact stores, or cloud CLIs. Run credential-dependent commands explicitly in a session after the instance starts, or keep them out of the build. Do not put tokens in setup scripts or commit credential files into the snapshot.