Inspecting your containers

The Olympus Free Container License grants every operator the right to inspect the source code of any container they are running. This page explains the practical mechanics: how to exec into a container, where the source lives inside the image, and which files are most useful to look at for which questions.

The intent is that when you observe a behaviour you don't understand, a log line, a startup failure, an API response shape, you can correlate it against the exact source that produced it.

What the OFCL permits

Per the Olympus Free Container License, you can:

• Run the official ghcr.io/olympusoss/* container images for your own organization or your customers.
• Exec into those containers and read every source file inside. The images deliberately preserve source rather than ship pre-minified bundles.
• Patch locally to fix issues in your own deployment.
• Contribute patches back to the upstream repositories.

What you can't do is repackage the modified source as a competing distribution. See the license page for the full framing.

The shape of a running container

Each Olympus app image (athena, hera, site) is a Next.js standalone build. Inside the container:

Identifying the image you're running

To know exactly which source you're reading, identify your container's image digest:

podman ps --format '{{.Names}} {{.Image}}'
# olympus-athena-1  ghcr.io/olympusoss/athena@sha256:abc123…

Then resolve the digest to a Git commit using GHCR's metadata:

gh api -H 'Accept: application/vnd.oci.image.manifest.v1+json' \
  /repos/OlympusOSS/athena/git/refs/tags/$(podman exec olympus-athena-1 cat /app/.git-sha)

If .git-sha is present, the value matches a commit in OlympusOSS/athena.

Reading the source inside a container

# Exec into the container
podman exec -it olympus-athena-1 sh

# List the source layout
ls /app/src/

# Look at a specific route handler
cat /app/src/app/api/identities/route.ts

# Tail the middleware (auth chain)
cat /app/src/middleware.ts

# Inspect the SDK encryption code
cat /app/node_modules/@olympusoss/sdk/src/crypto.ts

The image deliberately does not strip comments, JSDoc, or developer-readable formatting. Whatever you see in the upstream repo at the corresponding commit is what you see inside the container.

What to read for which question

Reading the Kratos and Hydra configs

Kratos and Hydra are not Olympus source, they're upstream Ory binaries. The configs (kratos.yml, hydra.yml, identity schemas) come from the platform repo and are mounted into the Kratos/Hydra containers at deploy time.

To see the running config:

podman exec ciam-kratos cat /etc/config/kratos/kratos.yml
podman exec ciam-hydra cat /etc/config/hydra/hydra.yml

The full Kratos config reference is at Reference, kratos.yml, and Hydra at hydra.yml.

Patching locally

The OFCL permits local patches to your deployed containers, useful for hot fixes or experiments. Since the image preserves source, you can edit a file in-place and restart the container:

# (Inside the container) edit a file
podman exec -it olympus-athena-1 vi /app/src/lib/some-handler.ts

# Then trigger a rebuild and restart of the standalone server
# (this depends on your specific image's entrypoint, for Next.js standalone you
# typically need to rebuild, so a local patch flow is more involved than for the
# upstream repo).

For sustained changes, the cleaner path is to fork the upstream repo, apply your patch in source, build your own image, and point your deployment at it. Contributing the patch back upstream is encouraged where the change is generally useful.

Where next

• License, the OFCL framing in full.
• Internals, overview, per-repo deep dives organized for inspection.
• Develop, Workspace setup, clone the repos for a fuller dev environment.