Most bad releases follow the same script. Something ships on Friday afternoon, an error rate climbs, and someone has to decide between a hurried hotfix and a rollback. Either way, the fix is another deploy, and it has to go through the same pipeline that just let the problem through.
Toggley is built to take that deploy out of the recovery. It is a hosted feature flag service from Albright Labs. You wrap new code in a flag, ship it switched off, and turn it on from a dashboard when you are ready. If it misbehaves, you turn it off again. Nothing redeploys.
Our tagline is “Release on Friday. Sleep on Saturday.” This post explains what that means in practice.
What Toggley does
A feature flag is a named switch your code checks before it runs something. With Toggley, the switch lives in a dashboard instead of in a config file or a database table you maintain yourself.
Here is the basic loop:
- Create a flag in Toggley and wrap your new code in a single conditional check.
- Control the rollout. Turn the flag on per environment, target specific users or groups, or serve it to a percentage of users.
- Ship or roll back. Flip the flag on for everyone, or switch it off if something goes wrong in production.
Flags are not limited to on and off. Toggley supports four flag types on every plan: on/off, text, number and JSON. A text flag can pick a banner color, a number flag can set an upload limit, and a JSON flag can carry a small block of settings.
Who it is for
Toggley is for developers and small teams who want to separate “the code is deployed” from “users can see it.” If you have ever written a feature_flags table, or kept a new feature behind an environment variable and redeployed to change it, Toggley replaces that.
It is a focused product. It does feature flags, percentage rollouts, targeting and the history around them. It is not an experimentation platform or an analytics suite, and we would rather be clear about that up front.
How your app reads flags
You can connect with an SDK or with a single REST call.
SDKs are available for Node.js, the browser, PHP (with Laravel support built in) and Python. The server SDKs download your environment’s flag configuration and evaluate flags inside your own process. That means two things:
- No network call per flag check. Checking a flag is a local lookup.
- Your users’ data stays on your servers. Attributes such as email or plan are used for targeting inside your app and are never sent to Toggley. The SDKs only send evaluation counts.
Server SDKs check for changes every 30 seconds. If Toggley cannot be reached, they keep serving the last configuration they received, so an outage on our side does not turn your flags off.
Here is what a check looks like in Node:
import { init } from '@toggley/node';
const toggley = init({ serverKey: process.env.TOGGLEY_SERVER_KEY });
await toggley.waitForInitialization(5000);
const context = { key: user.id, email: user.email, plan: user.plan };
if (toggley.boolVariation('new-checkout', context, false)) {
// on for this user
}
The browser SDK works differently. It uses a public client key and asks Toggley for the current user’s values. Only flags you mark as Available to client-side SDKs are included, so flags for unreleased work do not leak into your page source. The browser package has no dependencies and is under 4 KB gzipped.
If your stack has no SDK, the REST API works from anything that can send an HTTP request:
curl -X POST https://my.toggleyapp.com/api/v2/client/evaluate \
-H "Authorization: Bearer YOUR_CLIENT_KEY" \
-H "Content-Type: application/json" \
-d '{"context": {"key": "user-123", "plan": "pro"}}'
Rollouts and targeting
On paid plans, you can release to part of your audience before everyone:
- Percentage splits per environment, down to fractions of a percent.
- Sticky assignment. Each user keeps the same variation, and raising the percentage only adds people.
- Individual targets, such as your own user ID or a customer who asked for early access.
- Rules on attributes you send, like email, plan or country.
- Segments, reusable groups such as beta testers or internal staff.
The flag page shows evaluations for each variation since a split started, so you can see how a rollout is actually landing.
Environments, history and cleanup
Every project gets named environments, so staging and production stay separate. New accounts start with Local, Dev, Stage and Prod, and each environment has its own keys and its own setting for every flag.
Every change is recorded with who made it, when, and an optional comment explaining why. When a flag has served one value everywhere for 30 days without changes, Toggley marks it stale, and organization admins get a weekly email listing stale flags. Old flags are how feature flag systems turn into clutter, so the reminder is there on every plan.
Pricing
Pricing is flat and published:
- Free: 1 team member, 5 flags, 4 environments, SDKs and REST API, 30 days of change history. No credit card.
- Basic, $9/month: up to 3 team members, 25 flags, 5 environments, targeting, percentage splits and 5 segments, 90 days of history.
- Pro, $19/month: up to 10 team members, 100 flags, unlimited environments, targeting, percentage splits and 50 segments, priority support, 1 year of history.
- Enterprise: higher limits and custom terms. Contact us.
Yearly billing saves about 10%. There are no setup fees or contracts, and you can upgrade or downgrade at any time.
Toggley is part of Albright Software, so one account and one bill covers it along with any other Albright Software app you add.
What it does not do yet
We would rather you find out here than after signing up. Flags, segments and environments are managed in the dashboard; there is no management API for creating or editing them. SDKs poll for changes rather than receiving a push, and there are no scheduled changes, approval workflows or Slack integration today.
Try it
Pick the next feature you are about to ship, wrap it in a flag, and deploy it switched off. Turning it on becomes a click, and so does turning it off.
Start toggling free. Five flags, no credit card, and no redeploy the next time a release goes wrong.