Remote Docker deployment

Ship Compose releases.
Keep failures contained.

Deploy containerized applications to kiosks, gateways, Raspberry Pi fleets and other remote Linux devices without opening a management port. Felania starts with a canary, validates health and expands only when the first target is safe.

Start 14 days free →Try the deployment demo

Outbound HTTPSDocker ComposeAudited operations

CONNECTIVITYOutbound-only agentWorks behind NAT and restrictive firewalls.

CHANGE CONTROLCanary before fleetProve the release on one target first.

VALIDATIONHealth-gated progressDo not treat a started container as success.

RECOVERYPrevious release readyContain a bad application update.

Why remote deployment gets risky

A working Compose file is only the beginning.

Remote devices add unreliable networks, inconsistent environments and limited physical access. A safe workflow must answer what happens before, during and after every release.

Manual SSH does not become a release process

Running commands one host at a time makes the operator responsible for ordering, status tracking and recovery. It also becomes hard to prove which version reached which device.

Targets drift when commands are interrupted.
Credentials spread across people and scripts.
A failed rollout can be discovered after users report it.

Centralize intent, keep execution local

The Felania Agent polls the control plane over outbound HTTPS, receives a bounded release task and executes Docker Compose on the device. The platform records each target state without exposing a remote shell.

One release definition for the selected fleet.
Per-device progress and failure reason.
Application lifecycle actions after deployment.

Release workflow

Four stages from intent to a healthy fleet.

Define the release

Choose the Compose workload, image tags, variables, target site or devices, and the health evidence that means the application is ready.

Prove the canary

Deploy to one device first. Felania waits for the Agent result and validation before the release can expand.

Roll out with visibility

Follow every target through queued, running, succeeded or failed states. Pause before a local issue becomes fleet-wide.

Operate the application

Start, stop, restart, deploy a previous version or uninstall while preserving the audit history and deliberate data boundaries.

Designed for real edge fleets

Keep the useful parts of containers. Add operational guardrails.

Felania is focused on application delivery and recovery for Linux devices already in the field.

BROWNFIELD

Keep the operating system

Use existing Debian, Ubuntu, OpenWrt or compatible Linux environments instead of rebuilding the fleet around a new image.

PRIVATE IMAGES

Pull from Registry V2

Store pull-only credentials, browse repositories and tags, and select the intended image while preparing a release.

AUTOMATION

Use the versioned API

Integrate device inventory, releases and bounded operations into the workflow your team already runs.

Questions

Remote deployment, without the mystery.

Does Felania require inbound SSH access?

No inbound SSH port is required for normal Felania operations. The Agent establishes outbound HTTPS communication and only executes supported, allowlisted tasks.

Can I deploy from a private Docker registry?

Yes. Add a pull-only Registry V2 credential, verify it, browse repositories and tags, then reference the selected image in the release.

What happens when the canary fails?

The release does not continue to the rest of the fleet. The failure remains visible per device, and rollback can restore the previous application release.

Can I self-host the control plane?

Yes. Felania Community provides a self-hosted path. Managed Cloud is for teams that do not want to operate the database, TLS, backups and platform updates.

Make the first device the safest place to learn.

Start with a no-card trial for up to 10 devices. Connect one Agent, create a release and see the guarded workflow before moving a production fleet.

Start free →Read documentation