Automatic Docker rollback

Detect the bad release.
Restore the last good one.

A container can start and still leave the application unusable. Felania combines canary deployment, explicit health validation and retained release history so a failed update can be contained and recovered on remote Linux devices.

Start 14 days free →See rollback in the demo

Health gatedPrevious release retainedPer-device result

BLAST RADIUSCanary contains failureThe fleet waits for evidence.

DETECTIONHealth defines successRunning is not the same as ready.

RECOVERYRollback stays availableReturn to a known release.

EVIDENCEEvery transition recordedSee target state and failure reason.

Recovery is part of deployment

A rollback plan should exist before the update starts.

When devices are in stores, factories or customer sites, “we will SSH in if it fails” is not a dependable recovery strategy.

Keep a known working application release

Felania tracks application releases rather than treating deployment as an unstructured command. That gives the operator an explicit previous version to deploy when the current change is unhealthy.

Release history remains visible.
Targets report their individual outcome.
A previous version can be selected deliberately.

Separate failure detection from fleet expansion

The canary receives the change first. Health validation must pass before remaining devices proceed, preventing one application defect from becoming a coordinated outage.

Stop at the first representative target.
Preserve untouched devices during investigation.
Use the same guarded path for the corrected release.

Safe recovery loop

Make failure boring and observable.

Retain release context

Record the Compose definition, image version and selected targets so the platform knows what is current and what preceded it.

Validate the canary

Run the release on one device and wait for the Agent to report deployment and health outcomes.

Stop unsafe expansion

If validation fails, keep the remaining fleet on its current working version and surface the failure for investigation.

Restore and confirm

Deploy the previous version, verify its health and keep the full operation in the audit history.

More than restart

Choose the recovery action that matches the failure.

Not every incident requires a new release. Felania keeps common application actions bounded and visible.

LIFECYCLE

Start, stop or restart

Recover a stalled application without granting a general-purpose remote terminal to every operator.

RELEASE

Deploy a previous version

Return to a known application definition when the current release cannot pass validation.

DEVICE

Run an allowlisted operation

Collect diagnostics or perform approved recovery actions with status and audit evidence attached.

Questions

Automatic rollback, clearly bounded.

Does rollback protect every device at once?

The main protection is staged expansion: a canary fails before the fleet changes. Each target also reports its own result, allowing failed devices to recover without hiding partial outcomes.

Is a running container considered healthy?

Not by itself. A release should use application-specific health evidence. Felania waits for the configured result instead of assuming process startup means the service is usable.

Can an operator deploy an older release manually?

Yes. Release history supports selecting a previous version and deploying it through the same tracked workflow.

What if the device is temporarily offline?

The operation remains visible rather than being mistaken for success. Once connectivity returns, the platform can receive new Agent state and the operator can decide the safe next action.

Plan the recovery before the release.

Use the free trial to connect a test device and walk through canary deployment, failure visibility and the previous-release path.

Start free →Read documentation