Remote operations for the devices you already run.

WHO IT IS FOR

Teams that operate devices in the real world.

QUICKSTART

From zero to a live device in three steps.

1. 1

   Create a device

   Open the console, choose Add device, then enter a unique name, site and device type.

2. 2

   Copy the device token

   The token begins with fle_ and is shown once. Store it on that device as a secret.

3. 3

   Install the agent

   Run the generated command as root. The device appears online and begins polling for allowlisted operations.

curl -fsSL https://felania.com/install.sh | \
  sudo sh -s -- fle_YOUR_DEVICE_TOKEN

What it installs: a small shell agent, a separate update runner, curl and jq if missing, a root-only configuration file and a systemd or OpenWrt procd service. The agent makes outbound HTTPS requests only.

GUARDED UPDATES

Automatic when you want it. Recoverable when it fails.

Each device can use Manual or Automatic update mode from Console → Devices. Manual mode is the default. Choose Update now or queue update_agent from Remote Operations to start a manual update.

Why the runner is separate: agent updates never overwrite the small process responsible for recovery. A device always keeps current, previous and pending-update state until validation succeeds.

RUNBOOK CONSOLE

Repeatable remote response without an open terminal.

Open Console → Runbooks to run a reviewed sequence of allowlisted operations across one or more devices. Felania validates every parameter on the server, executes steps in order and keeps a per-device transcript with status, timing and bounded output.

Risk and approval model

Create a custom Runbook

1. 1

   Describe the response

   Owners choose Create Runbook and give the playbook a clear name and purpose.

2. 2

   Add validated steps

   Select one to eight operations. Fields such as service, target, log lines and heartbeat interval use the same validation as Remote Operations.

3. 3

   Run on a canary

   Select compatible Agent 1.7 devices and keep the default canary strategy for multi-device work.

4. 4

   Review the transcript

   Each run preserves its Runbook version and rendered steps, so later edits cannot change historical evidence.

Security boundary: Runbooks do not accept arbitrary shell, pipes, redirection or undeclared parameters. Service logs can contain application secrets, so grant console and API access only to trusted operators and rotate exposed credentials if sensitive output is captured.

Start a Runbook through the API

curl -X POST https://felania.com/api/v1/runbooks/rb_system_network_path/run \
  -H "Authorization: Bearer fla_YOUR_PLATFORM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "deviceIds": ["dev_FIRST", "dev_SECOND"],
    "strategy": "canary",
    "parameters": { "TARGET": "felania.com" }
  }'

APPLICATION RELEASES

Canary first. Fleet only after health passes.

Felania Releases deploys a Docker Compose workload through the existing outbound agent. Open Console → Releases, enter an application name and version, paste the Compose file, select compatible devices and run deployment preflight before rollout.

services:
  app:
    image: ghcr.io/example/media-control:2.4.0
    restart: unless-stopped
    environment:
      DATABASE_URL: ${DATABASE_URL}
    ports:
      - "8080:8080"

Browse a private Registry V2

1. 1

   Add and verify credentials

   In Console → Releases, enter the HTTPS registry host, username and plaintext password or access token. For htpasswd, use the original password—not the bcrypt hash stored in the password file. Felania validates /v2/ before encrypting the credential.

2. 2

   Inspect a tag

   Choose Browse images, select a repository and then Inspect image. Felania reads its Registry V2 manifest, immutable digest, size and supported platforms such as linux/amd64 and linux/arm64.

3. 3

   Use the pinned image

   Choose Use pinned image to place an @sha256: reference into the Compose release. A later push that changes the original tag cannot silently change this release.

Deployment preflight

curl -X POST https://felania.com/api/v1/releases/preflight \
  -H "Authorization: Bearer YOUR_PLATFORM_API_KEY" \
  -H "Content-Type: application/json" \
  --data @release.json

Rotate or correct a login: choose Update login on the saved Registry card, enter the plaintext password again and select Verify & update login. The existing encrypted credential remains unchanged if verification fails.

Compatibility: the Registry must expose the Docker Distribution V2 catalog and tag endpoints. Some hosted registries or pull-only scoped credentials intentionally deny _catalog; those credentials can still deploy an explicitly entered image reference.

Application lifecycle controls

Device requirements: Felania Agent 1.7.0, Docker Engine and either Docker Compose v2 or docker-compose. Secret values and registry tokens must be one line. Anyone with root access to a target device can inspect its runtime environment, so device operating-system security still matters.

EDGE APP BLUEPRINTS

Deploy a supported app without writing Compose.

Open Console → Releases and choose a Blueprint. The guided form asks only for the image or version, ports and required encrypted variables. Felania renders a server-validated Compose file, shows a safe preview, then uses the same canary health gates and immutable protected snapshots as a manual release.

Trigger a Blueprint from GitHub Actions

1. 1

   Create an API key

   In Console → API, create a dedicated key and save it in the GitHub repository secret FELANIA_API_KEY.

2. 2

   Copy the generated workflow

   On a Ready Blueprint card, choose GitHub Action and save the result as .github/workflows/felania-deploy.yml.

3. 3

   Add Blueprint secrets

   If the Blueprint declares secret variables, create GitHub repository secrets with the same names. Non-secret values are workflow inputs.

4. 4

   Run the workflow

   Use Actions → Deploy with Felania → Run workflow. Supply an immutable version and a JSON array of target device IDs.

Safe automation: give each repository its own Felania API key, keep the workflow permission at contents: read, pin image versions and revoke the key when the integration is retired.

CORE CONCEPTS

Devices, sites and telemetry.

Every device belongs to one workspace and one site. A device identity is independent of its hardware, so it can represent a Linux computer, OpenWrt router, ESP32, gateway or another connected product.

Each heartbeat includes CPU, memory, disk, Wi-Fi signal when available, hostname, IP address, uptime, load average, kernel, agent version and operating-system metadata. Felania retains telemetry for 30 days by default.

Device lifecycle

Console workflow: open Console → Devices and choose Archive. Archived identities appear below the active inventory with Restore and, when safe, Purge controls.

Find a device quickly: search by device name, site, OS, hostname, agent version or platform. Sort the active inventory by attention status, name, site, last seen or version. The same search also filters archived identities.

STATUS MODEL

A small state model you can trust.

TOKENS & SECURITY

Two credentials, two responsibilities.

Never place a Platform API key in browser JavaScript or firmware distributed to customers. Create separate keys for each integration and revoke them from the console when no longer needed.

PLATFORM API

Connect Felania to your own product.

Create a Platform API key from Console → API. Send it as a Bearer token on every management request. The API is versioned under /api/v1 and returns JSON.

curl https://felania.com/api/v1/devices \
  -H "Authorization: Bearer fla_YOUR_PLATFORM_API_KEY"

const response = await fetch("https://felania.com/api/v1/summary", {
  headers: { Authorization: `Bearer ${process.env.FELANIA_API_KEY}` }
});

const fleet = await response.json();
console.log(`${fleet.online}/${fleet.total} devices online`);

Platform API keys are limited to 120 requests per minute per key. Device heartbeat limits are separate.

API REFERENCE

Available endpoints.