Skip to content
Lobby
Esc
↑↓navigate↵open⌘Jpreview
On this page

Builds And Services

Give managed services write-only environment values and renewable AWS access.

Development environments let an application run with the values it needs without putting credentials in Git, .env, setup commands, or an agent’s terminal. Lobby stores values above the workspace and releases them only when a signed-in user starts the declared service.

Declare the service

Add version 2 of .coding/workspace.json to the repository. A service accepts one credential binding by name:

{
  "version": 2,
  "cwd": ".",
  "setup": [],
  "services": {
    "app": {
      "command": "npm",
      "args": ["run", "dev"],
      "port": 3000,
      "readinessPath": "/",
      "credentials": ["app-development"]
    }
  }
}

The binding is repository-scoped. Setup commands, other services, agents, and interactive terminals do not inherit it.

Environment secrets

Open Settings → Development environments → Environment secrets. Select the repository, enter a binding name and one or more variables, then choose Save without reveal.

Values are encrypted in transit and at rest. After saving, Lobby returns only the variable names and binding metadata; there is no reveal action. Use Replace values to submit a complete new set. Do not use this store for public configuration that can safely live in the repository.

The selected service receives the values as ordinary environment variables. Lobby redacts exact issued values from captured service output, but application code can still transform or transmit them. Give the service only the network and upstream permissions it needs.

AWS cloud roles

Use an AWS role instead of uploading access keys or a developer’s AWS SSO cache. Open Settings → Development environments → AWS cloud roles, select the repository, enter the role ARN and AWS region, then create the binding.

Lobby shows a trust statement containing its exact AWS principal and a unique external ID. Add that statement to the customer role, choose Verify, then Enable. Keep the role policy narrow—for example, allow only the development Secrets Manager and KMS resources needed by this repository.

When the service starts, Lobby assumes the role for one hour and exposes AWS’s standard container credential provider variables:

AWS_CONTAINER_CREDENTIALS_FULL_URI
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
AWS_REGION
AWS_DEFAULT_REGION

AWS SDKs and the AWS CLI refresh through that endpoint automatically. Static AWS keys and SSO sessions never enter the workspace.

Trust boundary

A Lobby project is the collaboration boundary: its agents and teammates share the checkout, Docker daemon, and localhost services. Credential release is narrower. Only the named managed-service process receives the binding; sibling services and terminals receive neither its environment values nor its AWS credential endpoint.

This is intentionally different from tools that inject a secret into an entire agent VM. Treat the selected service and every dependency it loads as trusted with that binding.

Disable, replace, and remove

  • Disable blocks new starts and refreshes. Stop and restart an already-running service for the change to take effect.
  • Replace values rotates environment secrets without revealing the previous values.
  • Rotating an AWS external ID requires installing the new trust statement, verifying it, and enabling the binding again.
  • Remove deletes the binding from Lobby. An AWS STS session already issued to a running service can remain valid for up to one hour; change the customer role itself when AWS-side denial must be immediate.

Network and private services

Credential bindings do not grant general network access. An AWS role service gets the regional Secrets Manager endpoint required for its SDK credential flow. PrivateLink, VPN, and private package-registry connectivity are separate network features and are not configured by adding a credential binding.

Verify the setup

Start the declared service from the workspace and check its normal health endpoint. For AWS, call aws sts get-caller-identity or read one explicitly allowed test secret without printing its value. Then confirm the same command fails from a sibling service or interactive terminal. Disable the binding, stop the service, and confirm a new start fails closed before using production-adjacent permissions.

Was this page helpful?