Registries and Environments

An Environment maps a Definition to one registry connection, an optional repository prefix, public context, secret names, a target platform, and a runner pool. Configuration is administered separately from workflow source.

Configure a registry

name: company
host: registry.example.com
plain_http: false

pyplines registry apply ./registry.yaml
pyplines registry login company --username automation-reader
pyplines registry info company

Use the registry host, optionally with a port, without a URL scheme or repository path. registry login prompts for a password; --password-stdin supports credentials supplied by automation. Skip login for an anonymously readable registry. Plain HTTP is intended for isolated local development registries.

Create an Environment

The local pool exists for initial use; enroll a compatible runner in it before running work. This example targets linux/amd64; choose linux/arm64 when appropriate:

name: development
registry:
  connection: company
  prefix: actions
pool: local
platform: linux/amd64
context:
  service_api: https://services.example.com

pyplines environment apply ./environment.yaml
pyplines environment info development
pyplines secret set development service_api_token

With this mapping, inspect-service@2026.10.1 resolves under registry.example.com/actions/inspect-service. It must actually exist with a compatible contract and platform; this name is illustrative.

A repository prefix is optional. Each Environment has one registry mapping, so organize or mirror the Actions needed by a Definition under that mapping.

Network and runner placement

For network-enabled Actions, set the Environment's network to the network configured as PYPLINES_ACTION_NETWORK on its runners. Provision that Docker network on each relevant host. Use matching platforms within a pool and separate pools for different architectures.

One Environment executes one Run's attempt at a time. Creating more runner capacity does not remove that Environment-level constraint. Separate Environments can run concurrently.

Update configuration

environment apply, registry apply, and policy apply read the current revision when the file omits it. Include revision to require a specific prior revision. Treat revision conflicts as a prompt to review another administrator's changes.

Environment changes can invalidate prepared inputs and approvals. Review waiting Runs when changing context or secrets. Keep credentials out of context; secret bindings receive separate protection.