Continuous

Continuous is an open source business platform for SMBs to hire, manage, govern, budget, evaluate, and coordinate human, AI, and robot workers.

The first runtime slice is Continuous Core: a persisted headless operating layer for entity, workforce, payroll, filings, compliance, payments, AI operations, generated UI, and evidence. Revenue workflows remain the first customer-facing worker demo, but they sit on top of this broader core.

Stack

• Next.js 16 + React 19 + TypeScript
• Postgres + Drizzle ORM/migrations
• Docker Compose with Next.js, Postgres, and Caddy
• GitHub Actions CI for lint, typecheck, tests, and build
• DigitalOcean droplet deployment through doctl, SSH, and Compose

Local Development

bun install
bun run check

If Docker is running locally:

docker compose up -d db
bun run db:migrate
bun run db:seed
bun run dev

Then open http://localhost:3000.

Core APIs

• /health reports Postgres-backed readiness checks.
• /core returns persisted core counts, active tasks, and recent events for tokened operators; POST /core accepts structured core commands: task.create, task.transition, object.upsert, adapter.upsert, connection.upsert, connection.health.record, entity.setup.record, worker.upsert, worker.transition, worker.run.start, worker.run.complete, event.ingest, evidence.attach, document.create, packet.prepare, document.packet.prepare, decision.record, approval.request, adapter.intent.record, rule.change.record, obligation.scan, capability.grant, budget.reserve, budget.charge, budget.release, ai.infer, object.link, view.publish, customer_signal.record, payroll.preview.record, payroll.preview.packet.prepare, external_action.record, control_plane.token_rotation.attest, control_plane.credential.upsert, control_plane.credential.revoke, and control_plane.session.review. Core read views use POST /core with view, core, and config. Core mutation requests accept only command, core, idempotencyKey, and config as top-level fields. ai.infer is the deterministic Core AI gateway: route selection, redaction, budget reservation/charge, inference, usage, audit, and evidence are written through one reusable command while live provider execution remains blocked.
• /approval is the shared approval control-plane API. Use POST /approval with view, approval, and config for inbox reads; use POST /approval with command: "approval.decide", structured approval, top-level idempotencyKey, and config for decisions. Approval requests accept only the read or command envelope fields as top-level fields.
• /worker is the canonical worker control-plane API. Use POST /worker with view, worker, and config for read views; use POST /worker with command, worker, idempotencyKey when required, and config for side-effecting worker commands. Worker requests accept only the read or command envelope fields as top-level fields; worker is limited to role, id, and tenant selectors, and every operation-specific input lives under config. Revenue operations runs can first call POST /worker with command: "lead.read", config.source, and config.records[] to persist Core lead source snapshots, then call command: "lead.classify", command: "response.draft", command: "quote.prepare", or the full command: "run" with the returned config.intake selector. The split classify, draft, and quote-preparation commands write worker run, inference, usage, event, evidence, approval/view, and audit proof while external send remains blocked. Internal workflow handlers can still use exact Core row ids; config.leadPacket remains a direct operator/test fallback. Revenue command schemas reject unknown top-level config fields, so known controls such as scheduler provenance and blocked externalSend are named explicitly, while source, provider, policy, receipt, and rollback details live in documented nested payloads rather than route-shaped fields. The route validates roles, commands, idempotency, tenant requirements, and external-execution posture through the worker command registry. Worker contract metadata also carries apiRoute: "/worker" so new roles inherit the route from the registry instead of creating a role-specific URL. Worker schema discovery exposes apiShape, a machine-readable contract for the canonical route, command/view envelope fields, worker selector fields, app-server tool names, and config paths so new clients do not infer API shape from the first Revenue role.
• Dispatch schedule proposals use the same shape: POST /worker with worker.role: "dispatch_operations", command: "schedule.propose", handoff ids in config.sourceRefs, and schedule requirements in config.constraints; the first slice writes only dry-run calendar receipts and approval records.
• /workflow is the canonical workflow control-plane API. Use POST /workflow with view, workflow, and config for overview and approval reads; use POST /workflow with command: "start", command: "transition", command: "steps.execute", or command: "approval.decide". Queued workflow execution can now prepare durable Core packets from packet-backed step kinds without adding packet-specific business-process routes. Workflow mutation requests accept only the read or command envelope fields as top-level fields.
• worker-scheduler is the internal production drain for queued platform work. It posts the same /workflow steps.execute envelope, polls active lead source connections with POST /worker payloads using command: "lead.read", hands returned selectors to command: "run", then drains /worker adapter retry/reconcile envelopes on a cadence; it does not introduce worker-family URLs or enable external execution. Worker-specific HTTP routes and local family-specific mutation shortcuts are intentionally absent; new worker families extend /worker and generic worker:tool / app-server surfaces by registering commands, views, and structured payload fields. App-server dynamic tools now expose continuous.core.*, continuous.worker.*, continuous.workflow.*, and continuous.approval.* surfaces, so agents can inspect Core, write Core primitives, inspect worker registries, run workers, inspect workflow state, and decide shared approvals without adding route-shaped worker-family tool names. The HTTP, app-server, and local worker read/command surfaces reject stray top-level operation fields so operation inputs stay under config.

Docs

• Core platform
• Open workflows
• Agent build path
• Revenue Operations Worker expansion
• Revenue Operations Worker V1 contract
• Worker expansion map
• Worker execution roadmap
• Worker readiness matrix
• Worker handoff contracts
• Owner Chief-of-Staff Worker V1 contract
• Dispatch Operations Worker V1 contract
• Finance Operations Worker V1 contract
• Workforce Operations Worker V1 contract
• Compliance Operations Worker V1 contract
• Systems Operations Worker V1 contract
• Local development
• DigitalOcean deployment
• Infrastructure notes

Deployment

The production host is a DigitalOcean droplet. Deploy to the configured domains:

./scripts/create-droplet.sh
HOST=45.55.53.92 ./scripts/deploy.sh

create-droplet.sh enables DigitalOcean managed backups by default and verifies the backup policy plus any available backup images before provisioning continues.

After DNS changes, refresh the Caddy site hosts without a full app deploy:

HOST=45.55.53.92 SITE_HOSTS="continuoushq.com, getcontinuous.app" ./scripts/configure-domain.sh

Caddy issues and renews the HTTPS certificates automatically for continuoushq.com and getcontinuous.app.

Before treating the droplet as customer-data ready, run the strict production readiness gate after backup scheduling, alerting, recovery-drill evidence, token rotation, and non-root host access are in place:

HOST=45.55.53.92 bun run ops:non-root-access
HOST=45.55.53.92 bun run ops:production-readiness-check

License

Apache-2.0. See LICENSE.