Developers / Software Engineers / Programmers

If you enjoy developing software more than configuring the containerized app you just created, dyrector.io is for you.

The platform helps you to spark up your containerized stack on any infra hassle-free, so you can spend more time doing things you like.

DevOps Engineers / SysAdmins

Imagine the platform as a hub where all the components of your infrastructure can be accessed, and containers can be started, shut down or restarted.

This hub not only grants you access to these resources, but also enables your teammates to interact with your applications in a self-service manner. You'll be only needed to help them with deployments and troubleshooting when necessary.

Indiehackers / Self-hosters

Tinkering with stuff is your passion, and we're here to help you with that. If a project you'd like to use has an OCI compatible image, you can set it up on your local machine, on-premises server or cloud infrastructure.

Tip for self-hosting enthusiasts: you can dyrector.io for free, unlimited, forever.

Startups / Organizations tired of vendor lock-ins

dyrector.io is the right platform for startups eyeing containerization. The platform's release management capabilities help you spend your funds on meaningful stuff instead of wasting valuable engineering hours on repeated, mundane tasks.

As an organization, you might already have invested in some type of infrastructure. Moving your services from that infrastructure is painful and resource-heavy. With the platform, it's completely unnecessary, because the platform can be used with your infrastructure right away. And in case you decide to leave the platform, you can do so by exporting YAML-files to avoid losing your data.

Registries are where the images you'd like to deploy are collected. While there are multiple registries explicitly supported, all OCI registries are supported. You can add registries from the following sources:

What is dyrector.io?

It's an open-source continuous delivery platform offering self-service deployment and configuration management capabilities via a GUI and API to any cloud or on-premises infrastructure.

You can find the project's repository on GitHub.

Demo (2 mins)

When to use the platform

• You already have a Kubernetes cluster and want to manage it with ease.

• Multiple users on your team need to have access to your containers for management.

• You'd like to configure versions once, without repetition.

• Your team needs self-service deployments for QA or sales purposes.

Platform introduction

UI & API for container management

A delivery platform that helps you by substituting Docker and Kubernetes command line interactions with abstractions. You're able to configure any OCI compatible containers with a configuration screen, and in a JSON-editor, as well.

You can use the platform by installing its agents on your infrastructure. The agent will communicate with the platform to conduct interactions with containers running on your infra.

Cloud provider & technology agnostic platform

The platform is ready to interact with your already existing infrastructure and clusters right away. The platform interacts with any existing cloud & on-premises infrastructure, as we don't offer infra. You can deploy images from any registry you have access to.

The platform can be used without moving your services to a brand new infrastructure. To provide quick setup, we don't offer any infrastructure to our users.

Integrations to the most popular tools

Chat notifications on Discord, Slack, and Teams let you and your team know about newly made deployments and versions to increase collaboration.

dyrector.io consists of 2 major components:

• an agent that's installed on your environment where you want to deploy images – crane is the agent that communicates with Kubernetes API and dagent is the agent for communication with Docker API, both written in Go –,

• and a platform (UI developed in React.js, Next.js. Backend developed in Node.js, Nest.js). Communication between the agents and the platform takes place in gRPC with TLS encryption. The data is managed in a PostgreSQL database mapped by Prisma ORM.

dyrector.io cloud (alpha access)

Self-managed

Self-hosted dyrector.io is free and will always be, without feature and usage restrictions.

Keep track of the actions your teammates execute. This way if a malfunction occurs, you can understand if it was due to a specific action or an outside factor.

We track user ID, time and unsensitive data related to actions on the platform. Audit logging on our platform only monitors actions executed by users via the platform.

We don't get access to self-managed team logs.

Team

A group of users working on the same project. Without an invite to a team, on your first login you must define a team. Later you can invite others to your team, they will have access to every data and components, including configurations and secrets that belong to the team. To limit access to the data of one team, create a new team that'll have its own components.

Teams can have multiple Nodes, Projects and Registries.

Node

Nodes are the deployment target environments where either of the agents are installed. A node can be any cloud or on-premises infrastructure. Without registering a node, your team can't use the platform. We suggest to be the first step you do after creating your team.

Node setups require admin or root privilege. Without that, it's not possible to the platform's agent on your node.

If you're curious about the install scripts of the agent, you can check them out at the link below:

Registry

Container registries where the images that you plan to deploy are stored. You can use any Docker Registry API V2 compatible registry with the platform, including Docker Hub, GitHub, GitLab, Google, Azure registries. Unchecked sources are supported, too, as long as they're V2 compatible. Docker Hub Library is available to every user by default.

Project

Projects are the fundamental building blocks of dyrector.io, as these are the deployable units that contains the images with the corresponding configuration. These are the stacks you’ll manage in dyrector.io. There are two types of Projects, as seen below.

• Versionless Project: these projects have only one hidden version and cannot be rolled back. These are mostly useful for testing purposes.

• Versioned Project: versioned projects can have multiple versions. The different versions can have different configuration and images. Semantic versioning is suggested.

Deployment

Deployment is the process of delivering the images that make up a project to the environment you added as a node by installing an agent on it. You can assign environment and configuration variables to the deployments, and also edit deployments depending on the type of project you want to set up on your node.

Versioned project deployment

• Rolling version

Rolling versions have one deployment per version on each node, because a new deployment will overwrite the existing stack on the node. These type of versions can have multiple deployment prefixes since you can deploy them to multiple nodes. Only In progress deployments of rolling versions aren't mutable and deletable. Once the deployment of a rolling version is complete, you can't adjust or delete that.

• Incremental version

You can deploy multiple incremental versions of the same project to a node, therefore different incremental versions can have the same deployment prefix. The first deployment of an incremental version is mutable as long as it's not In progress. Incremental versions can have multiple deployments with the same prefix, but only one of them can have Preparing status. Only In progress deployments can't be deleted. After deploying an incremental version, the deployment will get one of the two statuses below:

Successful: successful deployments remain immutable. After successful deployments, you can roll back the previous version with the corresponding database.

New successful deployments turn previous ones that belong to older versions obsolete. When a previous version gets rolled back, the deployment that belongs to it turns all the deployments coming after downgraded.

Failed: if a deployment comes back failed, it can be mutable.

Versionless project deployment

Versionless projects come without a version. The purpose of versionless projects is to reduce infrastructure maintenance overhead.

Use cases:

• Messaging queues: RabbitMQ, MQTT, etc.

• Proxies: Traefik, NGINX, etc.

• Databases: Postgres, MySQL, etc.

Audit log

Audit logs collect team activity. It lists executed actions, the users who initiated them and the time of when the actions happened.

Logs are assigned to teams.

Profile

Your user profile. One profile can belong to multiple teams.

Rolling versions are similar to versionless project in a way that they come with a version that can't be rolled back. They’re always mutable but contrary to incremental versions, they aren’t hierarchic and lack a version number.

Step 1: After picking the Rolling tag, click ‘Save’. You’ll be directed to the Project tab. Select the project again.

Step 2: Click ‘Add version’.

Step 3: Enter the rolling version's name and specify a changelog.

Step 4: Click 'Save'. You'll be directed to the board of versions of your versioned project.

Step 5: Click 'Images' button in the card that belongs to the version you'd like to assemble.

V2 Registries are Docker Registry HTTP API V2 compatible. Both private and public registries are supported.

Add a private registry

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Step 2: Enter your registry’s name and select an icon.

You can create configuration bundles which you're able to apply to deployments later. These are templatized key-value pairs for environment variables.

• Configuration bundles are shared between the members of a team.

• Configuration bundles act as .env files.

• Multiple bundles can be applied to a deployment.

The platform is currently in the making, and so is its pricing. The public alpha hosted by us is completely free. If you want to give the platform a try , you can do it, free of charge, forever.

Our plan with pricing is to have one, limited free package, and multiple paid plans with different usage caps. Paid users will have access to prioritized support compared to free users, and they're going to be able to manage more nodes, projects, and deployments in the platform.

is a painless self-hosted Git service. It is similar to GitHub, Bitbucket, and GitLab. Image is available with latest tag on dyrector.io.

After the Node where you'd like to run Gitea is , you can set it up by following the steps of deployments as documented .

Once the deployment is successful, Gitea is ready to use at by default, as seen below.

Find out what's in the works on , or check out coming features and integrations we have in mind at the links below.

You can inject files into a container using S3 storages by following the steps below.

What you'll need:

• An S3 API compatible storage available

Add your storage to the platform

Step 1: Navigate to Storage on the platform and click the Add button at the top right corner.

Step 2: Enter the following information to their respective fields:

• Name

• Your storage's URL

• Access key

• Secret key

Step 3: Click Save.

Add a bucket in your storage to a container

Step 1: Navigate to your projects and select the project that has the container you'd like to inject files to.

Step 2: Click on the gear icon on the right side of the container.

Step 3: If it's turned off, turn on the Storage filter in the sub filters.

Step 4: Select the storage you'd like to inject files from, and enter the bucket path.

If you’ve created a versioned project, you’ll need to add a version to it. This version could be a rolling or an incremental version.

Step 1: Open Projects page on the left and select the project you want to set a version to.

Step 2: Click ‘Add version’ on the top right.

Step 3: Define a name for your project’s version in the name field.

Step 4: Enter a changelog if you’d like to.

Step 5: Select if you’d like to make this a rolling or an incremental version. Click here for more details on the difference between the two.

Step 6: Select if you’d like to turn this into a default version all the future versions will automatically inherit images and their configurations.

Step 7: Click ‘Save’ on top right.

Container routing

Container routing is available for nodes where Traefik is enabled on node install.

Expose strategy of the container you wish to be exposed should be set to HTTP or HTTPS, instead of none. In the routing section of the configuration screen, you need to specify a domain and a port. The additional variables are optional.

When a path is specified, the Traefik container will exclusively route requests with URLs containing that designated path prefix.

Enabling path stripping will result in forwarding the request without including the specified path.

The generated Traefik router's name will be automatically generated as "prefix + name."

If the router uses HTTPS, all necessary Let's Encrypt labels will also be added. It's important to note that middlewares can only be applied by adding them as custom Docker labels.

Docker labels

If you have Docker labels set for your container, you can specify them as key-value pairs in the config screen under the Docker labels section.

Vaultwarden is an unofficial self-hosted Bitwarden implementation. Image is available with latest tag as a template.

After the Node where you'd like to run Vaultwarden is registered, you can set it up by following the steps of deployments as documented here.

Once the deployment is successful, self-managed Vaultwarden is ready to use at localhost:80 by default.

Versionless projects have only one abstracted-away version and cannot be rolled back. These are mostly useful for testing purposes or single-container stacks.

Step 1: On the Project tab, click ‘Add’ on top right.

Step 2: Enter the project’s name.

Step 3: Select the versionless type under the description.

Step 4: Click ‘Save’. You’ll be directed to the Project tab. Select the project you just created.

Step 5: Click ‘Add Image’.

Step 6: Select the Registry you want to filter images from.

Step 7: Type the image’s name to filter images. Select the image by clicking on the checkbox next to it.

Step 8: Click ‘Add’.

Step 9: Click on the ‘Tag’ icon under the actions column left to the bin icon. This will allow you to select a version of the image you picked in the previous step.

Step 10: Click ‘Add Image’ to add another image. Repeat until you have all the desired images included in your product.

1. Go to sign up or login.

   • If you just signed up, check the inbox of the e-mail address you added for confirmation e-mail and verify your account with the link.

2. Create a team.

3. On the nodes page a new Docker or Kubernetes orchestrated node.

4. to the platform. Docker Hub is available by default. Bypass this step and step 5 by saving one of the as a project.

5. .

6. to your project.

7. the images if needed.

8. Deploy. 🎬

How it works?

After the CI/CD pipeline builds and pushes the image to a container registry, the pipeline triggers the deployment on the platform. The platform automatically signals to the agent that it should pull and start the image with the tag that already exists on the node.

Generate CD token

Step 1. a versioned project.

Step 2. Add a rolling version to the project.

Step 3. Add images to the version.

Step 4. a deployment to the version.

Step 5. Click Create in the Deployment token card.

Step 6. Enter a name for your deployment token and set its expiration time, then click Create. You'll need to generate a new one when the token expires.

Step 7. Save the token somewhere secure as you won't be able to retrieve it later. Click Close when you're done.

Step 8. Paste the curl command into the pipeline.

How to revoke token?

You can revoke the token by clicking on the Revoke token button in the Deployment token card.

Unchecked means image availibility checking is disabled. Any HTTP API V2 compatible registry can be added this way, but images and their tags cannot be browsed when assembling a project. You can add an image to a project from an unchecked registry by entering the image's exact name and when needed, the tag.

How to add an unchecked registry?

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Step 2: Enter your registry’s name and select an icon.

Step 3: Select Unchecked Registry and switch the toggle under the URL field to ‘Private’.

Step 4: In the corresponding fields, enter the registry's URL.

Step 5: Click ‘Save’ button on the top right.

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Step 2: Enter your registry’s name and select an icon.

Step 3: Select GitHub Registry type.

Step 4: Select if you'd like to add an organization or a user.

Step 5: In the corresponding fields, enter:

• Your GitHub user name,

• Personal access token generated in GitHub with the steps documented . Select the repo and read:packages scopes. Repo scope is required due to GitHub's limitations. You're still able to add public GitHub registries, too.

• And your organization’s or your user's GitHub name.

Step 6: Click ‘Save’ button on the top right.

WordPress is the most popular CMS. More than 43% of all websites are managed with it. You can quickly set it up wherever you'd like to manage your content with WordPress. Image is available with latest tag.

After the Node where you'd like to run WordPress is registered, you can setup WordPress by following the steps of deployments as documented here.

Once the deployment is successful, WordPress is ready to use at localhost:4444 by default, as seen below.

dyrectorio/.env.example

dyrectorio/web/crux/.env.example

dyrectorio/web/crux-ui/.env.example

dyrectorio/golang/cmd/crane.env.example

dyrectorio/golang/cmd/dagent.env.example

Monitoring allows you to get instant feedback whether a deployment was successful or not, as seen below.

Besides deployment feedback, the platform is useful when you need to check up on your infrastructure and all you need to do is check the platform to get logs.

Nodes are the environments that'll be the target of your deployments.

Self-service container management

The platform abstracts away interactions with containers. You can deploy images, start, restart, and delete containers with the platform. Logs and container inspection allows you to dig deeper into a container's operation when needed.

Add a Private Google Registry

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Step 2: Enter your registry’s name and select an icon.

Production

Use .

Pilot

Step 1: Open the project or version you would like to deploy. To demonstrate the process, we used a versionless project.

Step 2: Click 'Add deployment'.

Step 3: Select the node in the 'Add deployment' block. After that, click 'Add' on the top right corner of the block.

Projects are the deployable units made up of images and their configuration you're going to manage through the platform.

Features

• Deployment – Initiate deployments to a single or multiple deployment environments called nodes. A node can be in any cloud, VPN, or on-premises environment.

is a CMF that allows developers to build APIs in Node.js. It's mainly used to build content-driven applications or websites. You can quickly set it up on your infrastructure. Both images of Strapi are available with latest tag.

After the Node where you'd like to run Strapi is , you can setup Strapi by following the steps of deployments as documented .

Once the deployment is successful, Strapi is ready to use at by default, as seen below.

Chat notifications help you to get informed about your team's activity in an instant. As of now 3 platforms are supported:

• Discord,

• Slack,

• and Microsoft Teams.

You can get notifications about 4 events:

API

You can opt for using unchecked registries, that means images are not checked at all, image URLs are passed to the agent straight away. This way you can skip setting up certificates for the API.

The environment variable is NODE_EXTRA_CA_CERTS, the process expects a concatenated list of your certificates. More info:

Concatenating pem files to a single file: cat *.cert.pem > node_extra_ca_certs

is used to how to build and deploy microservices-based applications using Google Cloud Provider (GCP). Google Microservices Demo allows users to demonstrate use of technologies like Kubernetes/GKE, Istio, Stackdriver, gRPC and OpenCensus. Users can quickly set Google Microservices Demo up on your infrastructure.

After the Node where you'd like to run Google Microservices Demo is , you can set it up by following the steps of deployments as documented .

Once the deployment is successful, Google Microservices Demo is ready to use at

Minecraft needs no introduction. You can setup a Minecraft Server by following the steps of deployments as documented . Image is available with latest tag as a template.

Once the deployment is successful, the server is ready to use at by default.

Join our community to discuss DevOps, Kubernetes or anything on our public .

You can find the project's GitHub repository . Feel free to contribute!

Check our to read posts written by our team of DevOps specialists to improve your processes.

Follow us on , , and to stay updated about the latest developments.

If you got any question or feedback, let us know at .

Docker Hub is a public image library. You can add registries from Docker Hub with the following steps.

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Step 2: Enter your registry’s name and select an icon.

Step 3: Select Docker Hub type.

Self-managed GitLab is an open-source version of GitLab to manage your code. It's key advantage is that users can configure GitLab to their needs. You can quickly set it up on your infrastructure. Image comes with latest tag in the template.

After the Node where you'd like to run GitLab is registered, you can set it up by following the steps of deployments as documented here.

Once the deployment is successful, self-managed GitLab is ready to use at localhost:21080 by default.

Incremental versions are hierarchical in a way that they can have child versions and once a deployment is successful, the deployed versions, the environment variables, and the deployed images can never be modified. Because of this, you’re able to roll back the deployed incremental version and reinstate the last functional version.

Step 1: After picking the incremental tag, click ‘Save’. You’ll be directed to the incremental version’s preview. Click ‘Add Version’.

Step 2: Enter a name and a change log for the new version.

Step 3: Click ‘Save’. You’ll be redirected to the project's version board.

Step 4: To add images, click ‘Images’ and ‘Add Image’ on the next view.

Step 5: Select the Registry you want to filter images from.

Step 6: Type the image’s name to filter images. Select the image by clicking on the checkbox next to it.

Step 7: Click ‘Add’.

Step 8: Pick the ‘Tag’ icon next to the bin icon under the actions column to pick a version of the image you selected in the previous step.

Step 9: Click ‘Add Image’ to add another image. Repeat until you have all the desired images included in your product.

Add new version to your incremental version

Step 1: Open Projects and select the versioned project you’d like to increase.

Step 2: Click ‘Increase’ button under the version of the project you’d like to add a new version to.

Step 3: Enter the version's name and add changelog. Click ‘Save’.

Step 4: Click 'Add image’ to search for images you’d like to include in the new version. If you’d like to remove an image from the previous version, click on the red trash icon.

Step 5: Pick the ‘Tag’, which is a version of the image you selected in the previous step.

MLflow is a platform to streamline machine learning development, including tracking experiments, packaging code into reproducible runs, and sharing and deploying models. The Docker image of MLflow is available with the 2.4.0 tag.

After the node where you'd like to run MLflow is registered, you can set it up by following the steps of deployments as documented here.

Once the deployment is successful, MLflow is ready to use at http://localhost:5001/ by default, as seen below.

LinkAce is a self-hosted archive to collect links of your favorite websites. You can quickly set it up on your infrastructure. Template consists of MariaDB (10.7) and LinkAce image with simple tag.

After the Node where you'd like to run LinkAce is registered, you can set it up by following the steps of deployments as documented here.

Requirements:

1. APP_KEY environment variable must be 32 characters long.

2. After deployment, exec in the linkace-app container and add chmod 777 privileges to the \app\.env file.

Once the deployment is successful, LinkAce is ready to use at by default, as seen below.

To setup Templates, users need a Node set up with either of the platform's agents. The deployment process is the same as documented. Some of the templates require a level of configuration before deployment. These are documented, as well.

Available templates:

Continuous Delivery

Manually triggered deployments at the end of a CD pipeline. Related features: scheduled releases. Configure your release and schedule a deployment time for the designated environment when the deployment won't be disruptive to users.

Bundled configurations

Misconfiguration induced failures are very common, especially when you don't have to regularly deal with configuration variables. Add human factor to the equation and the chances of outages induced by faulty configurations increase significantly.

For this reason we're working on a feature that allows users to manage bundled configurations. This way you'll be able to treat your configurations in a templatized manner.

Changelog generation

Unawareness of how one version of your image is different from another is a risky practice. To avoid this, the platform helps you create changelogs based on your commit messages with Conventional Commits service. Make sure developers working on your application leave meaningful commit messages, so everyone working on your project understands the details of each version.

Changelog generation can reduce knowledge gap between stakeholders, like developers who work every day on the project and outsiders who occasionally deal with the project, like decision-makers.

Besides the changelogs, you can also leave a comment related to nodes and projects on the platform which your teammates can see on the platform's UI.

Use cases

• Auto send changelogs: once the changelog is generated, you can send it via e-mail or chat, whichever your team uses to communicate. For further information, check the ChatOps section.

Secrets management

You can use HashiCorp’s Vault Integration for secrets management to keep your passwords and encryption keys secure. This means the platform compliments your DevSecOps practices. Your secrets will be securely stored by HashiCorp, which you can access through the platform.

HashiCorp Vault is the de facto tool of security, used by most organisations. We encourage our users to use it, as well.

Use cases of HashiCorp’s Vault

• General Secret Storage: store your secrets, including sensitive configurations, tokens, API keys. Query them by using vault read.

• Employee Credential Storage: instead of using sticky notes around your screen, store and distribute credentials in one place. Vault has an audit log mechanism, which lets you know who had access to one of the stored secrets. This simplifies monitoring which keys have been rolled or not.

• API Key Generation for Scripts: generate temporary access keys for the duration of a script. The keys only exist for that duration and are logged by HashiCorp.

Role Based Access Control - RBAC

Role based access control allows you to manage the privileges of other users. This is an extra measure of security to your infrastructure and data. Using RBAC helps you to avoid situations when someone has unauthorised access to your account to execute harmful actions.

Use cases

• Principle of Least Privilege: consider the tasks of each user having access to your infrastructure. Only give them privileges necessary to complete their tasks, including modifying and managing configurations.

ChatOps

The platform's functionality implemented into ChatOps commands.

YAML export

In case you decide to stop using the platform, you can generate YAML files to easily setup their services using another platform without using data.

Portainer is a popular Docker GUI for containerized applications. It supports Docker, Docker Swarm and Kubernetes orchestrated runtimes.

The most important difference between Portainer and dyrector.io is the feature-rich release management capability the latter offers for containerized applications. You're able to configure and deploy your application's containerized stack with dyrector.io.

While you can trigger multi-instance deployments with dyrector.io, Portainer offers single-node deployments.

Which to choose?

Portainer is very useful for teams who would like to interact with containerized applications and their infrastructure in a simple manner. Its Community Edition leaves room for many Docker specific use cases, but some premium features are only available in the Business Edition which offers limited usage for free users.

dyrector.io offers more for teams who develop their own software and want to manage its versions as a containerized stack, and then deploy them to a single or multiple deployment targets with a single click. Self-managed dyrector.io is 100% open-source without usage limitations.

Functionalities compared

Step 1: On the Product tab, click ‘Add’ on top right.

Step 2: Enter the Product’s name.

Step 3: Select Complex on the switch under description.

Step 4: Click ‘Save’. You’ll be directed to the Product tab. Select the Product you just created.

Step 5: Click ‘Add Version’.

Step 6: Enter a name and a changelog for the new version. At this point, you can choose whether you’d like to create a Rolling or an Incremental product.

Cal.com is a meeting scheduler application. Users can set up its self-hosted stack.

Why use dyrector.io to set up Cal.com

Cal.com is awesome. We like it and use it everyday, people like it, too. Chances are, if you're here, you like it, as well. Even better that they provide self-hosted usage. But as some users pointed out on , self-hosting Cal.com is a challenging process. So, we turned it into a template for easy setup.

File injection to containers is possible with the Storage function. It's S3 API compatible, as of now only Azure Blob Storage isn't supported.

We decided to go with S3 API compatible storages as it’s one of the most popular technologies that offer interoperability with a fair number of open-source projects. They represent a bunch of functions as flat structure file storages, including versioning, different types of access control, and so on.

One example of S3 API use cases is to upload the object via a REST endpoint and the object will be available through a simple URL.

Can I use dyrector.io without containerization?

Unfortunately we don't support applications that don't run in a containerized environment.

Is dyrector.io Kubernetes specified?

GitLab CI/CD & GitHub Action

The platform isn’t a CI/CD tool but it covers certain steps of CD and its release management related aspects.

Both GitLab’s CI/CD and GitHub’s Action tools can be integrated. Its main benefit is that the platform enables you to manage multi-instance deployments to different environments, and it enables you to manage several different configurations. You can bring multiple services and operational practices under the same hood.

Add SaaS GitLab Registry

Step 1: Open Registries on the left and click ‘Add’ on the top right.

Proxies provide secure connection when you set up the platform for self-managed use. But they can be useful for any other uses, when you need a firewall, or you'd like to hide your location, and so on.

When you set up the platform, we highly recommend you to use a proxy, such as Traefik or NGINX, to secure your network.

Traefik

Traefik is used by default, as seen in the designed for production use.

Configurations can be all over the place without a single source of truth when left unmanaged for long periods of time. The more configurations you need to deal with, the more likely you’ll lose track of them. The platform can be used as single source of truth for all of your configurations, while being able to add, remove or modify configurations directly or via the JSON editor.

Every configuration you specify will remain stored after any modification or deletion to ensure you won’t have to spend time again defining already specified configurations.

How is it better than using a Git repository?

Git repositories containing the configurations of your microservice architecture can be all over the place because one repo won’t cover all the configurations for all the images & components in your architecture. The platform substitutes Git repos by bringing every variable that belong to a specific Product in one place.

Our main goal is to provide you with fast and reliable open-source services. To achieve this, we collect performance data about the navigation and the application feature usage, and send anonymous usage statistics to our servers. This data helps us track how changes affect the performance and stability of our open-source service and identify potential issues.

We are fully transparent about what data we collect, why we collect it, and how it's transmitted. The source code for the telemetry package is open-source and can be found here. If you do not want to share telemetry data and help improve our projects, you can opt out of this feature.

Data Processing

To provide a clear understanding of why we collect data, how it's collected, and what we do with it, as well as real-world examples of how this data has improved our projects, let's break down the data processing pipeline:

1. Telemetry data is collected from the browser.

2. This data is periodically sent to eu.posthog.com.

3. The data is stored and analyzed using the PostHog platform.

Our data processing pipeline has been designed with specific goals in mind:

• To track the number of dyrector.io installs.

• To understand which features are in use and how they are utilized.

• To evaluate the frequency of specific feature usage.

• To detect issues introduced by new features, such as buggy releases.

Opting Out

1. You have the option to disable quality assurance features, also known as telemetry, by using the environment variable QA_OPT_OUT=true. Disabling telemetry doesn't have any drawbacks, except that it prevents us from making improvements to the project.

Data Privacy

In order to safeguard your privacy, we take several measures to protect your data:

1. We are unable to access or store the IP address of your host or users. Our PostHog project's "Discard client IP data" is active, thus we are not able to identify who sent the data. You can find a comprehensive list of transmitted URL paths in the Request Telemetry section.

2. We do not transmit any environment information from the host except for:

   • Operating system (e.g., Windows, Linux, OSX)

All this information is stored in an aggregated format without any personally identifiable data, ensuring your privacy is protected.

Identification

To facilitate the identification of installations each running instance is assigned a unique identifier generated using a Universally Unique Identifier (V4). This identification process is triggered when we are confident that the instance is not a test instance, such as a tutorial or a local installation.

The system metrics we collect include:

• $os: The operating system of the user's device.

• $browser: The web browser used by the user.

• $device_type: The type of device used, such as "Desktop" or "Mobile."

These measures allow us to effectively manage and group installations while maintaining data security and privacy.

Source code

The full code-base is open source.

Example

Dependencies

Before using the CLI, make sure you have the following dependencies installed on your local machine:

• Docker installed on your system but works, too.

0.10.0

Introduced node connection improvements: node kick option is added, fixed an issue with updated agents getting kicked, and added an agent connection mechanism which will attempt connection with the stored token first, then the environment token if the first attempt fails. Delivered a fix to agents occasionally crashing when a container is deleted. Fixed deployment logs and container events logs overwriting each other. Added Rocket.Chat and Mattermost notification integrations. Added working directory as a container option. Integrated PostHog for quality assurance purposes (more details about it ) - tracking can be disabled. Private Docker Hub registries are now supported. Added healthchecks to CLI upon up command. Added show icon feature to relevant pages. Minor fixes and improvements.

Shouts to chandhuDev for his contribution in this release.

Registries

Registries are 3rd party registries where the images of versions are located. Learn more about registries here.

Projects

There are two kinds of projects in dyrector.io: versionless and versioned. Versionless projects make up one deployable unit without versioning, while versioned projects come with multiple rolling or incremental versions. More details .

Versions

Versions belong to versioned projects. Versionless projects act similar to a rolling version of a versioned project.

The purpose of versions is to separate different variations of your project. They can be either rolling or incremental. One versionless project can have multiple versions of both types. More details about rolling and incremental versions .

Version/Images

Images make up a versioned project's version, or a versionless project.

Teams

Teams are the shared entity of multiple users. The purpose of teams is to separate users, nodes and projects based on their needs within an organization. Team owners can assign roles. More details about teams .

Users/Me

Users/Me cover endpoints related to your user profile.

Deployments

Deployments are the process that gets the installation of your versions or versionless projects done on the node of your choice. More details about deployments .

Tokens

Tokens are the access tokens that grant you access to a user profile and the teams the profile is a member of.

Nodes

Nodes are the deployment targets. Nodes are registered by installing at least one of the agents – crane for Kubernetes, dagent for Docker. These agents connect the platform to your node. One team can have as many nodes as they like.

Node installation takes place with Shell or PowerShell scripts, which can be created or revoked. More details .

Audit log

Audit log is a log of team activity generated by the platform.

Health

Health refers to the status of the different services that make up the platform. It can be checked to see if the platform works properly.

Notifications

Notifications are chat notifications in Slack, Discord, and Teams. They send an automated message about deployments, new versions, new nodes, and new users. More details .

Templates

Templates are preset applications that can be turned into a project right away. They can be deployed with minimal configuration. More details about templates .

Dashboard

Dashboard summarizes the latest activities of a team.

Storages

Storages are S3 compatible memory storages. They can be used for file injection. More details .