# dyrector.io puts a container deployment platform on your own infrastructure

> dyrector.io is a self hosted continuous delivery and deployment platform for OCI containers, built from a Go agent, a Nest.js backend, a React and Next.js interface and a PostgreSQL database, with Docker, Kubernetes and Podman support. The trade is that the control plane is yours to operate, and the published releases are well behind the current development branch.

**dyrector-io/dyrectorio** — dyrector.io is a self-hosted continuous delivery & deployment platform with version management.

- Repository: https://github.com/dyrector-io/dyrectorio
- Website: https://dyrectorio.com
- Stars: 1,844 · Forks: 130
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/dyrector-io-dyrectorio

## The control plane and the agent split

The architecture section of the README describes the project in one sentence, and that sentence is the whole deployment model. dyrector.io consists of an agent, written in Go, and a platform, whose UI is developed in React.js and Next.js and whose backend is developed in Node.js and Nest.js.

There are two types of agents, one for Docker and another for Kubernetes. They talk to the platform over gRPC with TLS encryption. The data lives in a PostgreSQL database, accessed through the Prisma ORM.

That split is the design decision that defines the product. The agent is the part that touches your infrastructure, and it is a Go binary, so it is a single artefact you can run close to the workloads. The platform is the part that holds the catalogue of applications, versions and environments, and it is a web application you run yourself. The consequence is that a deployment does not require the platform to have network access to the Docker socket or to the Kubernetes API, only the agent does, and the agent can live inside the cluster it manages.

The Go module confirms the scope. It requires Go 1.25.9, and the dependency list includes google.golang.org/grpc and protobuf for the wire protocol, the Kubernetes client libraries at k8s.io/api, apimachinery and client-go for version 0.34.1, sigs.k8s.io/gateway-api, the Docker client at github.com/docker/docker v26.1.5, github.com/google/go-containerregistry for registry access, gopkg.in/yaml.v3, the urfave/cli command line framework, and the golang-jwt library for tokens. The protobuf/ directory in the repository is where the service definition lives, and the Makefile points its package variable at github.com/dyrector-io/dyrectorio/protobuf/go, so the gRPC contract is generated rather than hand written.

## The stack is more services than the README's architecture line suggests

The docker-compose.yaml in the repository shows what the platform actually is at runtime, and it is a multi service stack rather than a single binary. The file itself says it is a minimal compose file meant to be extended using files from the distribution/compose folder, and it points at GETTING_STARTED.md for the setup.

The first service is the database, from the image ghcr.io/dyrector-io/dyrectorio/multi-database:1.0.4. It gets three passwords from the environment, ROOT_POSTGRES_PASSWORD, CRUX_POSTGRES_PASSWORD and KRATOS_POSTGRES_PASSWORD, which tells you that there is more than one database and more than one application using it. The healthcheck is a pg_isready call against the crux database with the crux_user, on a five second interval with five retries, and the crux service waits for that healthcheck with a depends_on condition of service_healthy.

The second service is crux, the backend, run with the command serve and the image tagged by DYO_VERSION, which defaults to stable. Its environment is long and instructive. There is a DATABASE_URL pointing at the crux database, KRATOS_ADMIN_URL and KRATOS_URL pointing at an internal Kratos service on ports 4434 and 4433, JWT_SECRET, ENCRYPTION_SECRET_KEY for encrypting stored credentials, SMTP_URI and FROM_EMAIL for mail, RECAPTCHA keys with a DISABLE_RECAPTCHA flag that defaults to true, and QA_OPT_OUT.

Kratos appears in the compose file and in the environment file but not in the architecture paragraph of the README. Traefik is the reverse proxy, and the environment file explains why: it composes additional compose files for Traefik and Traefik labels, sets DOCKER_SOCKET, and provides DOMAIN, ACME_EMAIL and TIMEZONE so certificates can be issued for the deployment.

## Environment variables are the configuration surface, and the CLI writes part of it

The .env.example file in the repository root is the real configuration reference, and it is more useful than the documentation because it is what the stack actually reads. The COMPOSE_FILE line shows the composition of compose files, naming the base docker-compose.yaml followed by distribution/compose/docker-compose.traefik.yaml, docker-compose.traefik-labels.yaml and docker-compose.mail-test.yaml, with a comment noting it reflects the old composition.

Most keys are placeholders you must replace. DYO_VERSION is stable by default and is the tag used for the images. DOMAIN is where dyrector.io will be available and is required for Traefik's certificate resolution, with ACME_EMAIL as the address Let's Encrypt notifications go to. NODE_ENV switches the Node services between production and development, and LOG_LEVEL accepts verbose, debug, info, warning or error in a hierarchy, where warning contains error.

Two values are not hand written. The ENCRYPTION_SECRET_KEY is described as the key for encrypting stored credentials, and the comment says it can be generated using the CLI, with this example.

```bash
docker run --rm ghcr.io/dyrector-io/dyrectorio/cli/dyo:latest generate crux encryption-key
```

The three database passwords are listed as generated strings, one each for the crux database, the Kratos database and the root user. Getting any of these wrong produces a stack that comes up unhealthy rather than one that fails loudly, so the order of operations matters: generate the encryption key, set the passwords, set the domain, and only then point Traefik at it.

## Make targets for the whole lifecycle, including an offline bundle

The Makefile at the root is a thin wrapper over the Go directory, and it doubles as a map of the supported workflows. The up target starts the stack fully containerised on a stable build, down stops it, and upd starts the stack with the local development configuration while downd stops that.

The cli target runs the dyo command directly from source.

```bash
cd golang/cmd/dyo && \
go run .
```

The compose-init target is the one worth knowing about, because it is how the compose configuration gets generated. It runs an interactive compose file config generator, calling the CLI with a generate compose subcommand and a compose-dir argument pointing at distribution/compose.

The export targets are the reason the platform can be installed where the internet is not reachable. export-minimal pulls the kratos, crux, crux-ui and dagent images with crane for the linux/amd64 platform, copies docker-compose.yaml and.env.example into an offline directory, and zips the result into a bundle named for the version. export-full does the same and additionally pulls Traefik and a mail testing image, so you get a full local stack.

```bash
crane pull --platform=linux/amd64 ghcr.io/dyrector-io/dyrectorio/web/kratos:latest offline/kratos.tar
crane pull --platform=linux/amd64 ghcr.io/dyrector-io/dyrectorio/web/crux:latest offline/crux.tar
```

Both targets preserve your existing.env by moving it aside and restoring it afterwards, and they overwrite the DYO_VERSION in a temporary.env so the bundle matches the version being exported. That is a careful piece of build hygiene, and it is the answer to the question of how to run a deployment platform on an isolated network.

## What the feature list claims, and what the use cases say about the audience

The key feature list in the README covers Kubernetes, Docker and Podman support, multi-instance deployment, instant test environments from any branches, environment management, secret and configuration management, auto-generated changelogs and release notes, workflow support, scheduled releases, audit log, container registry integrations, fine-grained RBAC, and chat and notification solutions.

The use cases section says more about who this is for. Manage environments without SSH or kubectl: replace multiple tools with a single platform and initiate deployments to multiple environments simultaneously instead of repeated manual processes. Instant test environments for QA: enable QA to configure and deploy various versions of microservices to test environments themselves, running arbitrary workloads on any accessible nodes. Manage container settings without access: a user friendly JSON editor so that editing container settings does not require direct access or expertise in JSON formatting, plus bundle configurations to avoid manual configuration for each container.

The last of those is the one that distinguishes the product from a thin deployment wrapper. Bundle configurations, a config editor, an audit log, fine-grained RBAC and version management together describe a platform aimed at an organisation with more than one environment and more than one person who deploys, rather than a developer with a single compose file.

The CD story is the GitHub Actions integration: configure versions and deployments of a containerized stack from any registry, then automate deployments by generating a CD token you can use with GitHub Actions.

## The alpha platform and the release gap are the two things to weigh

Two facts in the README qualify the whole product, and an adopter should read both before committing.

The first is the deployment options section. Besides the self-hosted instance, there is an alpha at app.dyrectorio.com, and the README says the platform is still in the works, that the database might be reset, and that it is not recommended for production yet. A managed SaaS version also exists, including a free tier.

The second is the release history. The listed releases are 0.15.4 from 2025-05-11, 0.15.3 from 2025-04-16 and 0.15.2 from 2025-04-15, and the default branch is develop rather than main. The last push was on 2026-10-13, so work continues on the development branch, but the newest published release predates that by more than a year. In practice, choosing between the stable tag and the develop branch is a choice between a pinned, released version and a moving one, and the images in the compose file are tagged by DYO_VERSION, which defaults to stable.

The licence is Apache 2.0, with the LICENSE file at the repository root, and the README states that this repository and most of the project's other open source repositories are licensed that way. The repository also carries the usual governance files, including MAINTAINERS.md, DEVELOPMENT.md, SECURITY.md, a CODE_OF_CONDUCT.md and a.chglog directory, which is the tool the changelog is generated with.

## Conclusion

dyrector.io fits a team that already runs its own Kubernetes or Docker hosts and wants a deployment interface, an audit log and version management without sending container credentials to a third party service. It is a poor fit if you want a hosted product, because the managed platform is a separate product with a free tier and a database that may be reset. Verify first which version you are deploying, since the latest published release is 0.15.4 from 2025-05-11 while the last push to the develop branch was on 2026-10-13, and generate the encryption key with the CLI before you fill in the rest of the environment file.

## FAQ

### What does dyrector.io actually consist of?

The README states that it consists of an agent written in Go and a platform whose UI is developed in React.js and Next.js with a Node.js and Nest.js backend. There are two agent types, one for Docker and one for Kubernetes, and they communicate with the platform over gRPC with TLS encryption, with data in PostgreSQL through Prisma.

### How do I set up a self hosted dyrector.io instance?

The GETTING_STARTED.md file in the repository holds the setup instructions, and the root docker-compose.yaml is described as a minimal compose file meant to be extended with files from the distribution/compose folder. The compose-init make target runs an interactive generator that produces the compose configuration for you.

### Can dyrector.io be installed without internet access?

Yes, the Makefile has export-minimal and export-full targets that use crane to pull the images and zip them into an offline bundle together with docker-compose.yaml and .env.example. The full export also pulls Traefik and a mail testing image.

### Which container runtimes does dyrector.io support?

The key feature list names Kubernetes, Docker and Podman support, and the architecture section describes two agent types, one for Docker and another for Kubernetes. The Go module depends on the Docker client and on the Kubernetes client libraries.

### How do I generate the encryption key for stored credentials?

The .env.example file documents that the key can be generated with the CLI, and gives the command docker run --rm ghcr.io/dyrector-io/dyrectorio/cli/dyo:latest generate crux encryption-key. The value goes into the ENCRYPTION_SECRET_KEY entry.

## Sources

- [dyrector-io/dyrectorio on GitHub](https://github.com/dyrector-io/dyrectorio)
- [License: Apache-2.0](https://github.com/dyrector-io/dyrectorio/blob/develop/LICENSE)
- [Project website](https://dyrectorio.com)
- [README](https://github.com/dyrector-io/dyrectorio/blob/develop/README.md)
- [Releases](https://github.com/dyrector-io/dyrectorio/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dyrector-io-dyrectorio