Swirls Cloud

Swirls Cloud is the managed runtime for your .swirls agents. You author .swirls files locally, deploy them to Cloud, and operate the deployed project in the dashboard. Auto-scaling workers and a verifiable audit chain are bundled in for hosted execution. Deploy with git push or swirls deploy. No CI/CD to maintain.

What's included

Every Cloud deployment ships with the full platform. No add-ons, no plugins.

• Durable execution: Steps are checkpointed automatically. Failovers resume without duplicate work.
• Auto-scaling workers: Workers scale with your queue depth. You pay for work that ran, not machines reserved.
• The dashboard: Inspect every execution as a trace, drill into spans step by step, and approve human-in-the-loop reviews.
• Audit log: Append-only record of who did what across every surface. Read it in the dashboard or query it with the SDK.
• Per-node secrets: Secrets are delivered at run time. A node sees only what the .swirls file declared it needs.
• Versioned deploys: Every deploy is an immutable snapshot. Roll back to any previous version from the dashboard.
• Team collaboration: Invite teammates, manage roles, and share the audit trail.
• Identity-scoped access: Declare role and policy blocks and each principal reaches only the agents and workflows their role grants.

Three pillars

Runtime managed

• Durable execution with automatic step recovery
• Auto-scaling workers based on queue depth
• The hosted dashboard: trace, inspect, approve
• Sleep, signal, and child-workflow yields

Governance enforced

• Short-lived credentials scoped per run, per node, and per tool call
• Per-node secrets, never ambient
• Append-only audit log across every surface
• Permissions bound to the workflow hash

Regulated production

• 99.9% uptime SLA on every Cloud account
• Row-level tenant isolation, per-tenant keys
• SOC 2 Type II targeting 2027

Good to know: The .swirls file is the security policy. Every permission, key, and token derives from what you wrote. Modify a file and old tokens stop working. See the security model for the full chain of trust.

Getting started

curl -fsSL https://swirls.ai/install | bash
swirls auth login

swirls configure

swirls deploy

git push

Deploy methods

Swirls Cloud supports two deploy paths:

Both paths compile every .swirls file in the project, validate the merged definition server-side, and store it as an immutable snapshot with its source files. You can use both on the same project.

Git deploys

Link a GitHub repository to a project on the dashboard's Integrations page: install the Swirls GitHub App, pick the repository, and optionally set a root path when your .swirls files live in a subdirectory. Pushes to the configured production branch deploy to production; other branches can deploy as previews or be ignored, per your branch rules. Every push gets a commit status that links to the deployment, and a push with no changes is skipped with a successful status. You can also trigger a manual deploy of any branch from the dashboard.

Active deployment and rollback

One deployment per project is active at a time. The active deployment is the one whose forms, webhooks, and schedules fire. Every successful deploy becomes the active deployment. To roll back, open Deployments in the dashboard and repoint the active deployment to any earlier successful snapshot. In-flight executions keep the snapshot they started with, so a rollback never disturbs running work.

The dashboard

Open a project in the dashboard to operate it. The major surfaces:

• Traces: the run and debug surface. Every workflow execution and agent session as a filterable list with a span waterfall per run. See Traces.
• Inbox: pending human-in-the-loop reviews and approvals.
• Agents: chat with deployed agents, with persisted session history.
• Triggers: the project's forms, schedules, and webhooks.
• Streams, Views, and Databases: browse stream records, spreadsheet views, and managed database tables.
• Deployments: versioned deploys with environment and source filters, plus rollback.
• Connections, MCP servers, and Secrets: outbound integrations and credentials, encrypted at rest. Vendor API keys are declared in DSL secret blocks (optionally type: managed for Enterprise platform keys).
• Access: assign member attributes that deployed role and policy blocks match on.
• Settings: project settings, trace content policy, and trace export destinations.

At the organization level: members and invitations, the audit log, inbound identity federation, and billing.

Plans and credits

Swirls Cloud meters usage in credits. Workflow node executions and agent chat turns consume execution credits from your plan's allowance; one-time top-ups and usage-based overage extend it. See Billing for how metering, budgets, and enforcement work, and swirls.ai/pricing for current plans and prices.

On self-serve paid plans, you declare vendor API keys in DSL secret blocks and set values on the Secrets page. Enterprise unlocks type: managed secrets so Swirls supplies platform keys.

Next steps

• Local Development: Author, validate, and deploy .swirls files from your machine.
• Billing: How credits, budgets, and usage reporting work.
• Traces: Inspect every run span by span.
• Agent Onboarding: Let AI agents register for Swirls on behalf of users.