Skip to main content

Fleet deployment

The model is built for fleets, thousands of hosts per client. One team key is the shared bootstrap for the whole fleet. Each host gets its own per-server key from the server after it registers, so you never distribute per-host secrets, and you never template per-host config, because the monitoring logic lives on the server.

The same one-liner everywhere​

Any configuration management tool just runs the same install command:

curl -fsSL https://get.wakora.io | bash -s -- --key <YOUR_TEAM_KEY>

Pass the team key from your secret store or an environment variable, not in plain text in shell history.

cloud-init​

#cloud-config
runcmd:
  - curl -fsSL https://get.wakora.io | bash -s -- --key <YOUR_TEAM_KEY>

Ansible​

- name: Install Wakora agent
  hosts: all
  become: true
  tasks:
    - name: Run installer
      shell: "curl -fsSL https://get.wakora.io | bash -s -- --key {{ wakora_team_key }}"
      args:
        creates: /etc/wakora

The creates: /etc/wakora guard makes the task idempotent, so re-running the playbook does not re-install.

Mass rollouts self-heal by design: registrations per key are rate limited on the server, and a host that gets throttled parks its key locally and keeps retrying, so a thousand-host playbook finishes registering on its own within a couple of hours with no intervention. Reinstalls of already-known hosts are never blocked by plan quotas.

Golden images and declared layouts​

For golden images the pattern is: install and register in the image build (or at first boot), then declare anything non-standard with the agent's own CLI. Location overrides land in wakora.conf and survive in the image; secrets are set per host, because they are machine-bound and never travel:

curl -fsSL https://get.wakora.io | bash -s -- --key <YOUR_TEAM_KEY>
wakora --set nginx.access-log=/www/logs/access.log
wakora secret set mysql-monitor --user monitor   # per host, reads stdin for automation

Auto-discovery still covers the normal case. You only declare what discovery cannot see.

Planned

A long declarative flag form on the installer itself (for example --nginx --mysql --nginx-access-log=/www/logs in the one-liner) is planned. Today the installer takes only --key; declarations go through wakora --set and wakora secret set after install, which cover the same ground.

Do not pass secret values inline, they are visible in the process list. Feed them through stdin, or set them on the host with wakora secret set. See Secrets.

White-label note​

Under an agency white-label, the binary and the service are still named wakora. White-label rebrands the console and the customer-facing value, never the agent itself. The agent is the neutral open engine.

Native package​

Planned

A .deb package for apt-based fleets is planned, onboarded with the same team key. Today the canonical path on every platform is the one-line installer above.