Can I see the value in the UI

No. The Credentials tab shows names, mount paths and last use. Values are never rendered.

What if my image only reads environment variables

Read the file into the variable in your entrypoint, or reference the credential in environment: with ${credential:NAME} . The file form is safer, so prefer it when the image supports it.

Does a credential bound to one container work in another

No. A binding names its container. That is the point: the grant is explicit, and its absence is a refusal.

Give a container a secret

A container reads its secrets from files under /run/secrets/. You bind a credential to the container once, and idapt puts the value there each time it starts.

Bind a credential

Open the container and go to the Credentials tab
Click Add binding and pick a credential
Start or restart the container. The value is now readable at /run/secrets/NAME inside it

In a Compose file, reference it the normal Docker way:

services:
  api:
    image: my-api:1
    secrets: [GITHUB_TOKEN]
secrets:
  GITHUB_TOKEN:
    external: true

The document holds the name. idapt supplies the file.

Why a file and not an environment variable

An environment variable is stored in the container's configuration, so it shows up in docker inspect, in /proc, and in every backup of that container, forever. A file on a temporary filesystem exists only while the container runs and is never written to disk.

Rotation and revoking

Because the files are written fresh on every start, rotating a credential takes effect the next time the container starts. Nothing to edit, nothing to redeploy.

Removing a binding is the same: the next start fails with a message naming the credential, rather than quietly running with a stale value.

What an agent can and cannot do

An agent passes credential names. It never sees, types, or receives a value. Three limits apply:

A credential marked not agent-injectable cannot be mounted by an agent at all
An automation or webhook running with no human present cannot mount credentials
At most five credentials per container

Logs and command output from the container are scrubbed of the values idapt mounted, so a service that prints its own token does not hand it to the model.

Scrubbing covers the credentials idapt supplied. A secret the service generates itself is not redacted, because scrubbing every high-entropy string would make logs unreadable without making anything safer.

FAQs

Containers

Run a Docker image or a Compose stack on your computers, and know what survives a restart.

Compose files

Bring your own Compose file, and fix the few settings idapt refuses.

Backup and restore

What a backup captures, how long it is kept, and the difference between restore and rebuild.

Up next

Backup and restore

What a backup captures, how long it is kept, and the difference between restore and rebuild.

Was this helpful?

Bind a credential

Open the container and go to the Credentials tab

Click Add binding and pick a credential

Start or restart the container. The value is now readable at /run/secrets/NAME inside it

In a Compose file, reference it the normal Docker way:

services: api: image: my-api:1 secrets: [GITHUB_TOKEN] secrets: GITHUB_TOKEN: external: true

The document holds the name. idapt supplies the file.

What an agent can and cannot do

An agent passes credential names. It never sees, types, or receives a value. Three limits apply:

A credential marked not agent-injectable cannot be mounted by an agent at all

An automation or webhook running with no human present cannot mount credentials

At most five credentials per container

Logs and command output from the container are scrubbed of the values idapt mounted, so a service that prints its own token does not hand it to the model.