charm init --template daemon starter. Use a daemon-oriented scaffold such as slack-bot or customer-support-agent, or start from openclaw and set runtime.lifecycle: daemon as required.
Use Case
Use this lifecycle for agents that need persistent background execution, scheduled behavior, or long-lived state.Prerequisites
- Charm CLI.
- A daemon-capable adapter such as OpenClaw.
- Production runner configured with Fly.io daemon settings.
Configuration Surface
Document these fields:runtime.lifecycle: daemonruntime.adapter.typepolicies
How Daemon Runs Work
- The runner receives a daemon lifecycle request.
- The runner prepares the agent bundle and environment variables.
- A machine is created or reused in the configured Fly.io app.
- The daemon process starts and continues running until paused, restarted, or terminated.
Auto-Recovery & Persistence
Fault Tolerance: Daemon machines deployed on the cloud runner are equipped with automatic recovery capabilities. If the underlying Fly.io machine goesoffline or is stopped due to infrastructure scaling or resource reassignment, the runner detects this state upon the next interaction and automatically issues a restart command to resurrect the container.
Important: Because daemon machines may restart automatically, you must pair them with an external runtime.memory.provider (such as Supabase or Redis) to persist state. When state is safely externalized, auto-restarts remain entirely transparent to the end user.
Production Requirements
The production runner must be configured with:FLY_API_TOKENFLY_APP_NAME- optional
FLY_REGION
Run and Publish
Operational Notes
- Daemon agents can cost more than serverless agents because machines may stay alive.
- Always test pause, restart, and terminate behavior.
- Avoid hardcoded local paths.
- Keep secrets in platform-managed environment variables, not source code.
