Strake is free right now.
Not because deploy safety has no value. Not because pricing does not matter. And not because I think free users magically turn into a business.
It is free because I need real teams trying it on real pull requests.
That is the only feedback that matters at this stage.
I can make the site cleaner. I can rewrite the homepage. I can tune the scoring rules in a local demo until they feel right. None of that tells me what happens when Strake comments on an actual PR and an engineer has to decide whether the verdict helped.
That is what I want to learn.
Was the GO obvious?
Was the HOLD annoying?
Did the CRITICAL verdict catch something the team would have shipped anyway?
Did the PR comment give enough context, or did the engineer still have to open PagerDuty, Datadog, Slack, GitHub, and a wiki tab to understand what was going on?
Those are product questions, not pricing questions.
I made the product smaller
Earlier versions of Strake were trying to explain too much at once.
Incident workflow. Runbooks. Service health. Deploy history. Dependency changes. Operational memory.
All of those pieces still matter. They are part of where Strake is going. But they were too much to lead with.
The first useful thing is much simpler:
Strake is a GitHub Action that tells you whether a deploy is riskier than it looks.
It runs in the pull request. It reads production context. It posts a GO / HOLD / CRITICAL verdict where the team is already deciding whether to ship.
That is the part I want people to try first.
Not a dashboard.
Not a new ceremony.
Not another place engineers have to remember to check before a release.
Open a PR. Run the gate check. Read the verdict. Decide whether to ship.
Why I moved it to GitHub Actions
The shift to GitHub Actions was not just an integration choice. It changed how I think about the product.
Most deploy-safety workflows ask you to leave the deploy decision to inspect the deploy risk.
That sounds small, but it is where the habit breaks.
If the answer is in another dashboard, someone has to remember the dashboard exists.
If the answer is in Slack, someone has to ask the right question in the right channel at the right time.
If the answer is in a wiki, someone has to know what to search for.
The PR is different.
The PR is already where the decision is happening.
That is where the gate belongs.
A green build tells you the code passed the checks it was given. It does not tell you production is already fragile. It does not tell you an incident is open on the same service. It does not tell you the last deploy failed. It does not tell you the dependency tree moved in a weird way. It does not tell you the runbook is missing.
Those are deploy-boundary questions.
They should show up before the deploy goes out.
GitHub Actions is boring in the right way. Teams already use it. It already runs on PRs. It already has a place to report status. Strake should meet the deploy decision there instead of asking teams to build a new habit from scratch.
Why free is the right first step
I do not want someone to ask, "Is Strake worth buying?" before they know whether Strake is worth using.
That is backwards.
The right first test is small:
Pick one repo.
Install the Action.
Open a pull request.
See whether the verdict is useful.
If the gate is noisy, I want to hear that. If it misses context your team cares about, I want to hear that too. If it catches a deploy risk you would have otherwise waved through, that is the signal I am looking for.
Charging too early would make the feedback worse.
People get polite when money is involved. They start evaluating plan limits, seat counts, procurement, and whether the pricing model maps to their org chart. I do not need that yet.
I need blunt product feedback from teams that actually ship production software.
So the first version is free to start.
What free does not mean
Free does not mean Strake is a toy.
It means the product is intentionally narrow right now.
The first question is:
Can Strake make one deploy decision better?
If the answer is no, a paid plan would not fix that.
If the answer is yes, the next questions get more interesting. More repos. Longer signal history. Team controls. Support. Security review. Better runbook workflows. Whatever a real production team needs before this becomes part of how they ship.
Those are good problems to earn later.
Right now, I would rather have five teams try Strake on one real repo and tell me exactly where the verdict is wrong than have fifty people admire a polished demo.
Who I want using it
Strake is not for teams with a mature release engineering group and years of internal deploy tooling.
It is for the teams in the middle.
You have customers in production. You ship through GitHub. You have PagerDuty or Datadog or Slack alerts or some mix of all three. You have runbooks somewhere, but they are not always where the on-call engineer needs them. You do not have a full SRE bench to build internal guardrails from scratch.
You still need to answer the same question before you push:
Is this deploy riskier than it looks?
That is what Strake is for.
Try it on one repo
The ask is intentionally small.
Try Strake on one repo.
Do not migrate your incident process. Do not rebuild your release workflow. Do not sit through a long demo if you would rather just see the thing work.
Install the GitHub Action, open a pull request, and judge the verdict.
If it is useful, keep going.
If it is too noisy or too quiet, tell me where.
That feedback is the whole reason Strake is free right now.
Rob is building Strake, a GitHub Action deploy gate for engineering teams that run production without a full SRE bench. Strake posts a GO / HOLD / CRITICAL verdict in the pull request using context from incidents, deploy history, dependency changes, service health, and runbooks.