Change production in seconds, not deploys.

Sarcio is a governed break-glass path, not a cowboy console. Patches are constrained operations — never arbitrary code — validated server-side, previewed in isolation, approved by a human (two approvers for risky changes), signed, time-boxed with a hard expiry, reversible in one click, and recorded on an append-only audit log.

Every patch is verified in the client against your workspace's own Ed25519 signing key before anything is applied. Even a fully compromised delivery channel cannot push an unsigned payload to your users. The server tier verifies in a sidecar you host yourself, with outbound-only connections, or on WordPress inside the plugin, and fails closed either way.

Every patch ships with the pull request that makes it permanent. When the PR merges, the patch retires automatically. Patches carry hard expiries with reminder emails, live patches sit on one dashboard, and a patch whose PR was closed or stalled is flagged as orphaned — a patch cannot silently outlive its fix.

The AI only drafts. A human previews every patch in isolation and approves it before it goes live, and risky changes require two distinct approvers. DOM and server patches are constrained operations validated server-side — the AI cannot emit arbitrary code into them. Module patches are built from your repository and reviewed like any code change.

Sarcio is built for review: per-tenant signing keys, role-based access control, TOTP two-factor authentication, OAuth sign-in, admin-only integrations that act as a bot or app rather than a person, envelope encryption at rest, scoped API tokens, an exportable append-only audit trail, Jira change tickets, and module builds that can run in your own CI instead of on Sarcio’s infrastructure.

Plans differ by size, not by capability: every plan ships all three patch kinds, every connector, and every security control. What scales is how many sites and members a workspace covers (1 site and 1 seat on Solo, 5 and 10 on Team, 25 and 50 on Scale) and its monthly AI allowance: 80 AI credits on Solo, 400 on Team and 2,000 on Scale, enough for up to 40, 200 and 1,000 AI-drafted fixes. Captured reports are kept for 30 days on Solo, 90 on Team and 365 on Scale, and each report’s screenshot is stored at up to 2 MiB on Solo and Team and 5 MiB on Scale. Credits measure the model work itself, so every AI call spends them, including pull request writing and failed attempts. Exceeding either allowance never blocks a report: drafting pauses for the rest of the month and reports wait for manual triage. The one place size shows through is the two-approver rule on elevated-risk changes: two different people must approve, so shipping those needs at least two seats. The reviewer who approves first rates each patch low or elevated, and only an elevated rating calls for that second approver. WordPress sites have their own plans, priced on sites rather than seats: WordPress for one site, Freelancer for three, Agency for ten and Agency Plus for fifty.

Yes. A workspace admin cancels from Settings → Plan & billing in the dashboard; you keep access until the end of the period you've paid for. You can change plan there too: upgrades charge the prorated difference and apply once paid, downgrades apply right away with the unused time credited to your next invoice.

Stripe retries the charge and your admins are emailed, and everything keeps working. If it is still unpaid after 14 days the workspace is locked: nobody can sign in until it is paid, and admins get a link to pay without signing in. Live patches on your sites keep running while locked. After 30 days unpaid the subscription is canceled.

No. Pull requests, checks and tickets come from a workspace connection that only admins set up, ideally the Sarcio GitHub App or a bot token, so nothing depends on one person. Members can link their own GitHub, GitLab, Bitbucket or Jira account so fix PRs and tickets name or @mention them; a link stores no token. An admin can also allow acting links, which are off by default: then a member can opt in so Sarcio approves the fix PR and posts the Jira go-live comment as them. Approval itself always happens in Sarcio, and nothing done on a Git host counts toward it.

The browser widget is a small self-contained script of about 19KB gzipped that loads asynchronously and never blocks rendering. Heavier capture features like screenshots are lazy-loaded only when a report is actually filed.