Hello, world!

Hi. We’re the team behind RedPennon, and this is the bit where we’re meant to say something grand about the future of software delivery. We’ll spare you and give you the honest version instead.

We built RedPennon because we were tired of the knot in your stomach the moment a deploy goes out. You tested it. It worked on your machine. It worked in staging. And still, somewhere in the back of your head, there’s a voice asking what happens when real users hit it. Feature flags are how you quiet that voice. You ship the code dark, turn it on for yourself, then a few teammates, then a slice of traffic, and you watch. If it goes wrong, you turn it back off. No hotfix at 11pm, no rollback, no incident channel.

That’s the whole idea. Everything we’ve built is in service of making that loop fast and boring.

So what is it, actually?

RedPennon is a hosted home for your feature flags. You create flags in the dashboard, decide who sees what, and your app asks our API which variation to serve, in real time, in single-digit milliseconds. We run our own rollouts on it, which means when something annoys us it gets fixed quickly. Dogfooding is a good forcing function.

What you can do with it today

We didn’t want to ship a toy, so day one is already fairly complete. The pieces that matter most:

• Flags that know what they’re for. Pick a type (Release, Experiment, Permission, or Ops) and RedPennon seeds sensible variations and starter rules, so you don’t land on a blank form. And no, a brand-new flag is never on in production by default. We’ve been burned by that one too.
• Targeting that reads like a sentence. Serve one variation to this user, another to that email domain, a third to a 5% slice. Ordered rules, by user id, email, IP, or a reusable audience. Start small and dial it up when your nerve holds.
• Environments that stay in their lane. Development, testing, and production each get their own API key and their own served values, so a change in dev never leaks into prod by accident.
• Audiences you define once. Describe beta-testers or enterprise-customers a single time and target them from any flag, instead of copy-pasting the same conditions everywhere.
• Evaluation that doesn’t make you wait. Flip a flag and it’s live immediately. No redeploy, no cache to bust, and a p95 under 50ms. Your users won’t feel it.
• SDKs for the languages you actually use. Node, Go, and Python clients that share one REST contract. On some other stack? It’s just an HTTP call, so curl works fine.
• Code references, so flags don’t go feral. Our CLI scans your repo in CI and shows you exactly where each flag lives, down to the line. No repo connection, no OAuth to babysit.
• A nudge when a flag has outlived its purpose. We point out the flags that have vanished from your code or haven’t been evaluated in weeks. Those are the ones you can finally delete without holding your breath.
• An audit trail, because someone always asks. Every change to a feature or a rule is recorded, along with who did it.
• Roles that match how teams actually work. Owner, Publisher, Member, and Viewer, with production guards that quietly stop the wrong person flipping the wrong switch.

Five minutes to your first flag

The fastest way to get the feel of it: sign up, create a project, grab an environment API key, and make a Release flag called dark-mode. We’ll seed an on/off variable and switch on targeting in Development for you. Then, from your app:

import { RedPennonClient } from "@redpennon/node-sdk";

const client = new RedPennonClient({ apiKey: process.env.RP_API_KEY });

// ask the API which variation to serve this user
const darkMode = await client.variableValue("dark-mode", false, {
  user: { id: "user-123" },
});

console.log(darkMode); // true, until you turn it off

Now go into the dashboard, switch targeting off, and run it again. You’ll get false on the very next call, with no deploy and no restart. That small moment, where the code does nothing and the behaviour changes anyway, is the one we built the whole thing around.

This is day one

There’s a lot more we want to build, and we’d rather show our work than promise a roadmap, so we’ll write about it here as it ships. If any of the above sounds like a problem you have, the best thing you can do is go break something safely.

Create a free account or poke around the docs first. Either way, welcome.