Frequently Asked Questions

Daployi is a container management platform that gives DevOps engineers, IT teams, managed service providers, and IoT operators a single, secure place to deploy, manage, and monitor containerised workloads across distributed environments. It supports Docker and Podman-based infrastructure and is designed specifically for teams managing multiple hosts or edge devices at scale – where manual, device-by-device management is simply not a viable approach.

Daployi is built for any team managing containerised workloads across more than one host. This includes DevOps and IT teams, managed service providers (MSPs) managing client infrastructure, SaaS companies deploying to distributed client environments, start-ups scaling container-based applications, and organisations running IoT or industrial edge device fleets. The platform is designed to be accessible for small teams while being capable enough for large distributed deployments.

Getting started takes minutes. You create a project, register your hosts by installing the lightweight Daployi agent with a single command, and you are ready to deploy. No complex infrastructure setup, no Kubernetes expertise, and no lengthy onboarding is required. Visit the Pricing page to choose a plan, or book a demo if you would like a guided walkthrough first.

Daployi is designed to be usable by a wide range of technical users, not just senior DevOps engineers. The platform’s interface is clean and intuitive, and features like deployment templates and parameterised variables mean that field operators or junior technicians can execute complex tasks through simple, guided forms – without needing to understand the underlying commands or container infrastructure.

Daployi works with Linux-based hosts running Docker, Podman, or compatible container runtimes. This covers a wide range of hardware – from standard cloud and on-premise servers to edge devices such as Raspberry Pi, industrial gateways, and IIoT hardware. If your device runs Linux and a supported container runtime, it can be managed through Daployi.

Yes. You can use Daployi for free forever for up to 2 nodes. Please visit the Pricing page for current plan options and trial availability. Daployi also offers a demo for teams who want to see the platform in action before committing – book a demo.

Deployment templates are versioned, reusable configurations that define everything needed to deploy and manage a containerised environment – including Compose files, environment variables, maintenance scripts, and alert settings.

Once a template is created, it can be applied to one device or thousands simultaneously. Templates are not limited to initial deployment; they can be used for maintenance tasks, log clean-up, script execution, data recovery, and any other operational workflow you want to standardise across your fleet.

A golden template is a single, comprehensive deployment template that handles the complete setup of a device from scratch – installing services, creating the required directory structure, setting credentials, and configuring variables. When a new device comes online and installs the Daployi agent (a single command), running the golden template handles everything else automatically. This means a new device can go from bare hardware to fully configured and operational with minimal manual intervention.

Yes. This is one of Daployi’s most powerful capabilities. You can create a script template, select any group of devices or your entire fleet, and execute it across all of them simultaneously with a single action. You can also define variables that operators fill in at execution time – such as date ranges, file paths, or batch sizes – so the same script can be used flexibly across different scenarios without editing the underlying code each time.

Every deployment in Daployi is versioned and stored. If a release causes issues – a bug in new code, a configuration error, or an unexpected environment difference – you can revert to any previous deployment version with a single click. Critically, the rollback restores not just the container image but the variables and full configuration state associated with that version. Rollbacks can be applied to a single device or across your entire fleet simultaneously.

Yes. Daployi supports multiple isolated Compose stacks running on the same host. Each stack has its own networks, ports, and configuration, keeping services fully separated. You can deploy, update, or roll back individual stacks independently without affecting other services running on the same device.

Daployi provides real-time host metrics including CPU, memory, disk, and network usage for every registered device. It also includes a process viewer showing active containers and processes with resource consumption, uptime monitoring with chart-based visualisation, and a full deployment and event history log – all available directly in the dashboard without needing external monitoring tools.

Yes. Daployi has been optimised to support Podman as well as Docker. Teams running Podman-based container infrastructure can register their hosts and manage deployments, scripts, and templates through Daployi in the same way as Docker-based environments. This makes Daployi a strong choice as a Podman container management tool for teams that have moved away from Docker or are running mixed container environments.

Daployi supports customisable alerts for device state changes, container failures, and resource threshold breaches. Notifications can be delivered through Slack, Discord, Google Chat, or any platform that accepts webhooks.

Yes. Daployi provides a secure in-browser terminal and file browser for every registered host. Authorised users can run commands, modify configuration files, and browse the file system directly from the dashboard — without needing SSH access, open ports, or shared credentials. All sessions are logged and protected by role-based permissions.

Yes. Daployi exposes a REST API that integrates with any CI/CD system that supports HTTP requests — including GitHub Actions, GitLab CI, Jenkins, and others. When a new image is built, tested, and ready for deployment, your pipeline can trigger Daployi to roll out the update across your entire device fleet automatically, without manual steps. A native GitHub Action is also available that handles the full deployment lifecycle within your existing workflow.

The Daployi GitHub Action is a pre-built workflow step you add to your GitHub Actions pipeline. When triggered – for example, when a commit is merged to your production branch – the action calls the Daployi API, initiates the deployment across your target devices or fleet, monitors deployment progress, and reports success or failure back to the GitHub pipeline. Your CI/CD pipeline gains full visibility of the fleet deployment as part of the same automated workflow.

No. Docker does not natively support automated CI/CD deployments across a fleet of devices. The common workaround – Watchtower – is a basic open-source tool that watches for image changes on a per-device basis, but it is not actively maintained and does not support pipeline integration, variables, or on-demand triggering. Daployi fills this gap by providing a purpose-built CI/CD integration layer for container fleet deployments across both Docker and Podman environments.

Yes. Daployi gives you fine-grained control over deployment timing. For example, you can configure a template so that devices receive notification of a new version from the CI pipeline but only apply the update at a scheduled time – such as midnight – or when a specific condition is met on the device. This is particularly valuable in operational environments where updates need to happen during maintenance windows or when equipment is in a safe state.

Yes. Scripts executed through Daployi can check for device-side conditions before performing an action. For example, a script can verify whether connected equipment is idle before pulling and installing a new software version – preventing data loss or service interruption during an update. This gives teams a level of deployment control that goes well beyond simple scheduled or manual triggers.

Yes. IoT and IIoT edge device management is one of Daployi’s primary use cases and a core reason the platform was built. Daployi is designed to manage large numbers of distributed devices – such as industrial gateways, IoT data collectors, remote monitoring hardware, and field-deployed edge nodes – without requiring physical access or individual device login.

Everything from initial setup to ongoing maintenance, updates, and data recovery can be handled remotely through the platform, making it a practical edge device management software solution for operational technology environments.

The Daployi agent is lightweight and initiates communication outbound from the device to the Daployi server – meaning devices do not need inbound ports open and can operate through standard network connections including cellular SIM cards. Script execution supports offline-first patterns, and deployments can be queued and applied when connectivity is available.

A common challenge in IIoT environments is recovering data from devices that went offline — due to power outages, load shedding, or network failures – leaving gaps in upstream data streams. With Daployi, engineers can write a parameterised recovery script once and execute it across all affected devices simultaneously.

Operators simply enter the relevant parameters (such as a date range) through the platform interface and Daployi handles the execution across every target device – no individual SSH sessions required.

Yes. One of Daployi’s design goals is making fleet operations accessible beyond the core DevOps team. A DevOps engineer or developer creates the templates, scripts, and variables once. Field operators or on-site technicians can then execute those workflows through the Daployi interface by filling in simple form fields – without needing to understand Linux, container runtimes, or the underlying script logic. This significantly reduces the skill barrier for day-to-day fleet operations.

This is where Daployi’s batch execution capability delivers the most immediate value. If an event – such as a regional power outage or network disruption – affects a group of devices simultaneously, you can select those devices, run a remediation script or template, and resolve the issue across all of them in a single action. What would otherwise require logging into each device individually becomes a task that takes seconds, regardless of how many devices are affected.

Registry credentials – such as tokens used to pull private container images from Docker Hub, Google Artifact Registry, or similar services – are encrypted and stored on the Daployi server, never on individual devices. When a deployment is initiated, credentials are passed to the device in memory only, used for that single image pull, and flushed immediately afterwards. The device never holds credentials in storage at any point, eliminating the risk of credential exposure from a compromised device.

With traditional device-level credential management, a token expiry across a large fleet means updating every device individually – a significant operational burden. With Daployi, you update the credential once on the platform, and all subsequent deployments automatically use the updated token. No per-device changes are required.

Yes. Daployi uses a project-based access control model where users are assigned roles with specific permissions within each project. Team members only have access to the devices and actions relevant to their role. Projects are fully isolated from one another – particularly important for MSPs managing multiple clients, where each client’s infrastructure must remain separate and secure.

Yes. Every deployment, configuration change, terminal session, script execution, and API call is recorded in a full audit trail. Logs can be filtered by project, user, event type, and time range – supporting internal operational reviews, compliance requirements, and accountability across distributed teams.

Yes. Daployi supports MFA via Google Authenticator, passkeys, and email-based verification, providing an additional layer of account security beyond username and password.

Yes. All communication between the Daployi platform and registered host devices is encrypted end-to-end. Devices register using unique tokens, and the agent initiates outbound connections to the server – meaning no inbound ports need to be open on the device, which significantly reduces the attack surface.

Balena is a strong platform for IoT fleet management but takes an opinionated approach – it is optimised around its own BalenaOS and specific hardware types.

Daployi is more agnostic: it works with standard Linux hosts running Docker or Podman, regardless of the underlying OS or hardware. This makes Daployi a better fit for teams with existing infrastructure who do not want to adopt a custom operating system. Daployi also provides more flexible CI/CD pipeline integration and broader host access tooling, including an in-browser terminal and file browser.

Kubernetes and Rancher are powerful orchestration platforms designed for large-scale, cloud-native workloads where high availability, auto-scaling, and microservices orchestration are primary requirements. They are also complex — requiring significant infrastructure investment, specialist expertise, and lengthy onboarding.

Daployi is not a Kubernetes replacement for those use cases, but it is a strong alternative for teams that need reliable fleet and edge device management without that overhead. If your workloads run on Compose files and you need to manage them across many distributed hosts, Daployi provides that capability without the complexity or cost of a full orchestration platform.

SSH-based management – logging into each device individually to run commands, push updates, or troubleshoot – is the most common approach for teams without dedicated fleet management software. It works for a handful of devices but becomes unmanageable as the fleet grows.

With Daployi, actions that would require logging into 50 devices one by one are executed once from the dashboard and applied simultaneously across every target device. Beyond time savings, Daployi adds audit logs, rollback, structured access control, and real-time observability that SSH-based management cannot provide.

No – Daployi makes DevOps engineers significantly more effective, not redundant. A DevOps engineer or developer still builds the templates, scripts, and workflows that Daployi executes. What Daployi eliminates is the repetitive, manual effort of applying those workflows device by device. It also lowers the skill floor for routine operational tasks, allowing less technical team members to safely execute pre-built workflows without risking misconfiguration.

Yes. Daployi’s project-based structure is designed with MSPs and multi-tenant environments in mind. Each client environment is organised as a separate project with its own devices, templates, users, and access controls. Projects are fully isolated – users assigned to one project cannot access another unless explicitly granted permission. This gives MSPs a clean, scalable way to manage multiple client environments from a single Daployi instance.

Within each project, team members are assigned roles that define exactly what they can see and do. A junior technician might have permission to execute pre-approved scripts but not modify templates or access the terminal, while a senior engineer has full administrative control. Access is scoped to specific projects, so team members only interact with the infrastructure they are responsible for.

Daployi is designed to scale from a handful of hosts to hundreds of devices without changing your workflow. Templates, batch actions, and API automation mean that adding new devices to an existing project is straightforward – install the agent, apply the relevant template, and the device is fully configured. There is no need to rewrite processes or adopt new tooling as your fleet expands.

Yes. New device onboarding requires a single command to install and register the Daployi agent. Once connected, running the appropriate deployment template handles all further configuration automatically – services, directory structures, credentials, variables, and scripts. For large-scale rollouts, this means new devices can be brought online consistently and efficiently without manual configuration steps on each one.

Yes. New device onboarding requires a single command to install and register the Daployi agent. Once connected, running the appropriate deployment template handles all further configuration automatically – services, directory structures, credentials, variables, and scripts. For large-scale rollouts, this means new devices can be brought online consistently and efficiently without manual configuration steps on each one.

Yes. Daployi offers prioritised email support and direct access to a Daployi expert for Enterprise plan customers. Documentation and API references are available at docs.daployi.io. If you need help getting set up, you can contact the team directly.