One pipeline, every tier of your stack
Sarcio's economics are simple: the verification engine is written once, and each runtime costs only a thin adapter. That's how one approved patch fixes a Node API, a Laravel app, a Spring Boot service, and a WordPress site at the same time.
Browser tier
The widget and the frameworks it understands.
Reporter + front-end fixes
A single ~19KB (gzipped) script tag adds in-page bug reporting (console, network, and screenshot context) and applies approved front-end fixes. Framework-agnostic — if it renders HTML, it works.
React
Code fixes replace the buggy component or function in your production build, with React left as its normal production build: open pages reload onto the fix, and every page loaded after renders it from the start.
Angular
A dedicated builder plugin covers both JIT and AOT production builds. Dynamically created components are re-created live with their state carried over; anything else reloads the page onto the fix.
Vanilla JS & Web Workers
No framework required: the vanilla runtime re-runs transitive dependents after a swap, and web workers apply patches forwarded over a verified bridge from the main thread.
Vite
A build plugin emits the build your app needs for live swaps — one line in your Vite config.
webpack
The webpack plugin does the same job as the Vite one, so mixed-tooling teams get identical behavior.
Server-side fixes
Four runtimes, one self-hosted sidecar.
Server patches are enforced by a single static binary you run next to your app — Kubernetes sidecar, Docker Compose service, deb/rpm with a hardened systemd unit, or a bare binary. Your app gets a small library that consults it; on WordPress the plugin does the job itself, and a PHP app on hosting that cannot run a service can too. If anything is wrong, your app runs its normal code.
Node.js
One npm package with adapters for Express, Fastify, Koa, Hono, and raw node:http.
PHP
A Composer package with Laravel middleware and a Symfony listener over one shared core, built for PHP-FPM's process model — plus an opcache-aware fast path for whole-file fixes. On hosting that cannot run a service, it can fetch and check signed fixes itself, without the sidecar.
Java
A servlet Filter and a Spring Boot starter on a pure-JDK core — no agents, no bytecode manipulation, nothing exotic to clear with your platform team.
WordPress
One plugin covers both tiers on any host, shared and managed hosting included, with no service to run: connect it with one click, review and approve fixes in the Sarcio Inbox inside wp-admin, and keep a fix on your site for good.
Deploy anywhere
The sidecar ships as multi-arch containers, deb/rpm packages, and signed binaries. Your app and the sidecar upgrade independently, never in lockstep.
Outbound-only
The sidecar pulls signed fixes from Sarcio — nothing connects into your network, and the socket between your app and the sidecar stays on your host.
Run the sidecar as
Kubernetes sidecar
A sidecar container in the pod, sharing the socket over an emptyDir volume — patches apply per-pod with no cluster-level privileges.
Docker Compose
A service beside your app sharing a named volume — the demo stack's own layout, and the fastest path to trying it.
deb / rpm + systemd
Native packages with a hardened systemd unit: sandboxed, unprivileged, and upgraded by your distro tooling.
Bare binary
One static binary with no runtime dependencies — copy it to the host, give it your site key, done.
Workflow
Your Git host, your tracker, your CI, your assistant.
Each of these connects with its own least-privilege credential. The permissions pages list the exact scope every one requests, and why.
GitHub · GitLab · Bitbucket
The permanent-fix PR/MR opens on whichever Git host hosts the repo, as your workspace's own bot: the Sarcio GitHub App, or a project or repository access token. It carries a sarcio/approval check, Sarcio reads your CI result back, and a refused PR is one click to retry.
Jira
The patch lifecycle mirrors into your tracker, ideally through a service account: a Bug ticket when the patch goes live (or on draft), a comment at each milestone with the approvers @mentioned at go-live, commit messages following your convention so links resolve, and a transition when the fix merges.
Your own CI/CD
Opt a site into remote builds and code fixes build inside your pipeline instead of Sarcio's — only the validated, checksummed artifact comes back, authenticated by a narrowly-scoped API token. GitHub Actions, GitLab CI, and Bitbucket Pipelines out of the box.
Claude and MCP clients
Review bug reports and AI-drafted fixes from Claude or any Model Context Protocol (MCP) client, signed in as yourself and audited under your name. Read and review; approvals stay in Sarcio. Set up the MCP server →
If it's in your stack, it's probably covered.
Start with the widget on one site — add tiers as you need them.
Create a workspace