Loopany: scheduled agent loops where the server never runs your code

Recurring agent work, with execution kept at home

Loopany exists for a category of work that cron and chat history both fail at: the recurring agent task. You describe a loop once, a daily health check, a weekly research digest, or a closed goal like follow up until it is fixed, and a small daemon on a machine you control runs it on schedule using your local coding agent. Results surface on a shared dashboard and on your team's notification channel.

The split is the product. The server only schedules, stores, authenticates and notifies; it never runs an LLM and never executes your code. Execution is BYOA, bring your own agent, through the @crewlet/loopany daemon on your machine with your credentials, files and tools, and only the artifacts you choose to sync come back. The framing is vendor-neutral on purpose: switch agents without rebuilding, because nothing on the server cares which agent you run.

Loops come in two kinds. Open loops are monitors or digests that run indefinitely. Closed loops have a finish line and complete themselves when the goal is met, which is a genuinely different shape from a cron entry that never knows whether its work is done.

The 5% argument, and whether it holds

The README makes an argument worth quoting in structure rather than in awe: most coding agents can already run on a cron or loop a task themselves, and that is the easy 5%, the timer. The claim is that the real work is the structure that lets you trust the loop.

Four structures are named. Durable state and logs across runs, so a loop never redoes work and accumulates context instead of restarting cold. A verifier, so results arrive with evidence rather than vibes. A contract and boundary that decide whether you can safely walk away. And an evolve pass: a periodic rewrite of the loop itself, tightening the contract, cheapening the trigger, folding mechanical steps into scripts, so the loop gets sharper and cheaper the longer it runs, where a DIY loop stays as dumb as day one.

The argument mostly holds. A timer is one line; provenance across runs, a team surface, and self-improvement are the parts nobody scripts twice after the first attempt. The honest caveat runs the other way: all that structure is also more surface to trust, and this project asks you to install a daemon with high permissions to get it, a trade the README itself flags.

One server, one daemon per machine

The runtime picture the README draws:

flowchart LR
  Server["Loopany server<br/>schedules · stores · auth · notifies<br/>zero LLM · zero code-exec"]
  Daemon["@crewlet/loopany<br/>on your machine"]
  Agent["Local coding agent"]
  Server <-->|"HTTP poll"| Daemon
  Daemon -->|"runs / reports"| Agent

A scheduler tick creates a pending run. Your bound machine's next poll claims it, the daemon runs the agent, and the result reports back, optionally posting to the loop's push channel. Because the agent runs on your machine, credentials, files and tools never leave it; the server stores only the bytes your loop chooses to sync.

Two refinements sit around that core. A deterministic pre-stage is an optional workflow body for cheap mechanical work before the agent is invoked, and when it fails, execution falls back to the agent with context rather than dying. The synced artifact home works in both directions: a loop folder in, a dashboard out, with front-matter products such as reports, kanban cards and calendars rendering as generative UI.

Notifications are per-team push channels, with Telegram and Feishu named and more implied, plus failure alerts, so a dead loop announces itself instead of silently stopping. A template market rounds it out: ready-to-run loops for code health, shipping, growth, ops and personal routines, grouped into bundles and browsable without an account.

Connecting a machine to a server

The hosted app is a sign-in at loopany.ai, or your own self-hosted instance, and for now you also need at least one machine you control to run loops. A brand-new workspace opens a guided setup that walks the whole path and is skippable at any point.

The connection flow is three steps. Sign in to the web app. Create a loop, where the New loop dialog hands you a short connect snippet carrying a server URL and a one-time connect-key. Connect your machine by pasting the whole snippet into your local coding agent, which connects the machine and builds the loop with you.

Day-to-day daemon control is a CLI, with npx @crewlet/loopany --help documented as the entry point. The cheatsheet maps to the usual lifecycle: up and a foreground variant connect and start the poll loop; status and down report and stop; log surveys a loop's recent runs with a transcript flag for full text; new and edit create or patch a loop as JSON config; and an update command upgrades the daemon in place. One-time keys and per-machine daemons mean rotating access is a re-connect, not a credential scramble.

Self-hosting the control plane

The server is one process. Prerequisites are Node.js 22 or newer and pnpm 8.15, pinned through the packageManager field, and the root scripts are the standard trio:

  "scripts": {
    "dev": "pnpm --filter @loopany/server dev",
    "build": "pnpm --filter @loopany/server build",
    "start": "pnpm --filter @loopany/server start",

Storage has two tiers, and the choice is deliberately loud. By default the server runs an embedded, file-backed pglite database, which is the local and light-self-host path and migrates itself in process at boot. For production there is Postgres plus an object store, and the Docker deployment prefers a transaction pooler connection with a separate direct URL for migrations.

The Dockerfile makes the failure mode explicit:

ENV NODE_ENV=production
ENV LOOPANY_DATA_DIR=/data
ENV PORT=3000
EXPOSE 3000

Without a DATABASE_URL, the built server requires an explicit opt-in to run the embedded database at the data directory, and the prestart script refuses to boot otherwise, exiting rather than silently starting an empty ephemeral database because a lost secret should be loud, not invisible. Port 3000 is exposed, build provenance is baked in as build arguments and surfaced at a health endpoint for deploy smoke checks, and a Fly deployment configuration ships in the tree.

Early-stage permissions, a licence to read, and the DIY route

The README carries an early-stage note that deserves equal billing with the features: the daemon runs with fairly high permissions on your machine, since it executes your coding agent with your credentials, and security hardening is described as continuous rather than finished. That is the correct disclosure, and it should shape deployment: run it on a machine whose blast radius you accept.

The licence situation needs one sentence of care: the repository ships a LICENSE file and the README badge says MIT, but GitHub's licence detection reports NOASSERTION, meaning the text does not match a recognised template. Read the file before redistributing. The last push was on 2026-08-17.

The alternative is the obvious one: cron, launchd or a scheduled CI workflow wrapping your agent directly. You get the timer and logs, and nothing else: no state across runs, no verifier, no shared dashboard, no team channels, no evolve pass, and every improvement is your own scripting. Loopany is betting that the structure around the timer is the product, and for a solo script that runs once a night the bet is wrong, while for a team whose loops matter, rebuilding that structure by hand costs more than adopting it.

Editorial conclusion

Loopany fits teams that already trust a coding agent with real recurring work and want state, verification, a shared dashboard and self-improving loops instead of a naked cron entry, with execution pinned to machines they control. It does not fit anyone unwilling to run a high-permission daemon, or solo users whose one nightly script needs none of this apparatus. Verify first: that the connect snippet flow works against your self-hosted or the hosted server, which tier your deployment boots in when DATABASE_URL is absent, and what the LICENSE file actually says given the NOASSERTION detection. The last push was on 2026-08-17.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. superdesigndev/loopany-platform on GitHub