One SDK. Guard checks run locally from a cached bundle. Feature flags, rate limits, observability, and automated CVE response in a single integration.
Liteguard runs in-process as a library. Guard checks stay local, while config refresh and telemetry move quietly in the background. No proxies, sidecars, or config servers to deploy.
Each guard is a named control point in your code with a default value, ordered rules, optional rate limiting, and telemetry. Start with the capability you need first, then expand from there.
// guard a feature in one line
if (liteguard.isOpen('new-checkout')) {
renderNewCheckout();
} else {
renderLegacyCheckout();
}
Wrap a named code path in a guard. Set a default value, add property-based rules, and change behavior from the dashboard without redeploying.
$ liteguard auto-instrument
# Scanning your codebase...
✓ Found 47 instrumentable endpoints
✓ Found 12 3rd-party integrations
✓ Found 8 critical code paths
# Adding guards...
✓ src/payments/stripe.ts +guard
✓ src/auth/oauth.ts +guard
✓ src/api/search.ts +guard
... and 64 more
Done! 67 guards created. Dashboard updated.Run liteguard auto-instrument and the CLI walks your codebase, finds API routes, third-party calls, and critical code paths, then wraps each one in a guard. Review the diff and merge.
data.transform disabled in 12ms
Liteguard maps which guards depend on which packages. When a CVE is published for a dependency, affected guards can be automatically disabled and fallback logic kicks in. Your app keeps running while you patch.
Install the SDK, start one client with a Project Client Token, and evaluate guards locally. Read the full Getting Started guide →
Add Liteguard to your project with your package manager of choice.
$ npm install @liteguard/liteguardCreate one client at startup with your Project Client Token, then start it to fetch the initial bundle.
import { LiteguardClient } from '@liteguard/liteguard';
const client = new LiteguardClient('pctok_live_...');
await client.start();Add guards in code, or run the CLI to auto-instrument your codebase.
// Option A: manual guards
if (liteguard.isOpen('my-feature')) { /* ... */ }
// Option B: auto-instrument everything
$ liteguard auto-instrumentLiteguard is designed so ordinary guard checks stay local while the hosted service coordinates config, telemetry, and recovery behavior around the edge of the request path.
Once the bundle is fetched, ordinary isOpen checks evaluate locally. Normal request-path checks do not call the network.
Guard bundles refresh in the background with cached ETag handling, so config changes arrive without redeploying your app.
If the control plane is temporarily unavailable, Liteguard keeps using the last known good bundle and retries in the background.
Signals are buffered and flushed asynchronously so telemetry and adoption inventory do not block application code.
If hosted Liteguard is ever discontinued, we will open-source the core components needed to keep existing Liteguard projects running and publish migration documentation.
Feature flags, rate limits, observability, and CVE response. One dependency.