DEV Community: Stefan Iancu

A self-hosted Google reCAPTCHA alternative (we ship it)

Stefan Iancu — Fri, 29 May 2026 06:29:01 +0000

You know the one. You're trying to subscribe to a newsletter, and Google asks you to identify all the bicycles. You squint at the photo. You miss one pixel. You get a new grid, this time with motorcycles, and you start wondering if you're the bot.

That's reCAPTCHA. It works, kind of. It also loads a JavaScript bundle from google.com on every page it appears on, ships your browsing behavior to Google's risk-scoring API, and gets flagged in nearly every cookie-compliance audit we've seen.

The captcha on orkestr is Altcha. Self-hosted, no third-party JS, no Google, no behavioral tracking. Users don't see a puzzle. There's a single checkbox and a quiet "verifying..." while the browser does some math. About a second, total.

This post is why we picked it over the better-known options. If you're looking for a Google reCAPTCHA alternative and you care about GDPR, this is the path we'd recommend.

The honest verdict, up front

For low-to-moderate traffic forms (signup, contact, comments, login) where you're not under sustained ML-driven attack: self-hosted Altcha is the right pick. No third-party calls, no GDPR paperwork, no user-hostile puzzles, a small widget loaded from your own origin.

For very high-traffic public surfaces under active attack by sophisticated operators (e-commerce checkouts, ticket drops, large social platforms) you probably still want a managed service with behavioral ML. Altcha's proof-of-work raises the per-request cost; at internet scale, a real bot farm absorbs it.

"Low-to-moderate traffic forms" is most of the internet. Altcha wins for most people.

How they compare

	Google reCAPTCHA v3	hCaptcha	Cloudflare Turnstile	Altcha (self-hosted)
Data leaves your origin	Yes (google.com)	Yes (hcaptcha.com)	Yes (cloudflare.com)	No
Behavior tracking	Heavy	Moderate	Light	None
JS bundle (gzipped)	300+ KB	250+ KB	85+ KB	34 KB, your origin
User puzzle	Often	Often	Rarely	Never
GDPR posture	US sub-processor	US sub-processor	US sub-processor	None, it's your server
Self-hostable	No	No	No	Yes
Cost	Free + paid tiers	Free + paid tiers	Free	Free (your CPU)

The "data leaves your origin" row is the whole point. Every other column flows from it.

What reCAPTCHA actually does

reCAPTCHA v3 (the "invisible" one) is not really a captcha. It's a behavioral fingerprinting library that returns a score between 0 (likely bot) and 1 (likely human). The score comes from Google looking at your browser, your IP, your mouse movement, your cookies, and crucially, your entire Google account state if you happen to be logged in.

That's a feature for fraud detection at scale. It's a legal and reputational risk for an EU business, because every form on your site becomes a Google data-collection endpoint. Schrems II turned every cross-border transfer to a US ad-tech company into a per-tool compliance question. reCAPTCHA is exactly that tool.

The compliance picture got materially worse on April 2, 2026. Google reclassified reCAPTCHA from data controller to data processor, which sounds like an internal Google detail but isn't. EU operators are now fully on the hook for GDPR compliance on every reCAPTCHA hit: a signed DPA with Google, an explicit legal basis documented in your privacy policy, and your team handling any data subject requests. Data still goes to US servers. The compliance burden didn't shrink, it moved to your desk.

EU DPOs ask the same question in different words: if you don't control the JavaScript on your login page, who does? It's worth sitting with.

Cloudflare Turnstile is better, but it's still Cloudflare

Turnstile is the industry response to reCAPTCHA-fatigue. It's free, the UX is good (most users see a checkbox, not a puzzle), and Cloudflare is more transparent about what it collects than Google has ever been. If you're not in the EU and you don't care about CLOUD Act exposure, Turnstile is a fine pick. It's the second-best option here.

For an EU-native deploy platform, though, every US sub-processor is a row on a DPA that EU buyers read line by line. We wanted captcha to be a thing on our origin, not a thing on someone else's. Turnstile doesn't get you there.

What Altcha does instead

Altcha replaces the "score-the-user" model with a "make-the-bot-pay" model. Proof of work.

The server generates a random salt, a nonce, and a target prefix, signs the whole envelope with an HMAC key only the server knows, and hands it to the browser. A Web Worker iterates a counter, combining it with the nonce and running PBKDF2-SHA256 each step, until the derived key starts with the target prefix. When it finds a matching counter, the server gets the challenge plus the solution back, verifies the HMAC, verifies the prefix match, and accepts the form.

The whole thing takes about a second on a modern laptop. A human doesn't notice. A bot farm trying to submit ten thousand forms per second per IP suddenly has to spin up real CPU per submission.

There's no third party. The challenge endpoint sits on your domain. The widget JavaScript serves from your origin. The HMAC key never leaves your server. There's nothing to add to a sub-processor list, because there's no sub-processor.

Two gotchas if you self-host Altcha

The integration is small. One new endpoint, one HMAC environment variable (openssl rand -hex 32), one React component for the widget. Two things are easy to miss, both worth flagging.

Don't let a CDN cache the challenge

We sit behind Bunny CDN for SSL and edge caching. Our first wiring of Altcha had a weird failure mode: legitimate users were intermittently getting "captcha already used" errors on first submit.

The cause was the obvious one in hindsight. The CDN was caching responses from GET /api/altcha/challenge. Two different users were getting the same signed challenge, the first submission consumed it via replay protection, the second user hit a 400.

The fix is one header:

@router.get("/altcha/challenge")
async def get_challenge():
    challenge = mint_challenge(hmac_key, cost=5000)
    return Response(
        content=challenge.json(),
        media_type="application/json",
        headers={"Cache-Control": "no-store"},
    )

If you're behind any CDN, set this or you'll spend an afternoon wondering why your captcha is mass-failing in production but works locally.

Replay protection needs a real store

The replay attack on a captcha is obvious: capture a valid submission, replay it many times. Most official Altcha libraries (Django, .NET, and others) ship with a replay store built in, so check yours before reinventing it. We rolled our own integration against FastAPI, which meant we added one ourselves. Redis SETNX keyed on the verified solution hash:

# Returns True if key was set (first use), False if it already existed (replay)
is_first_use = await redis.set(
    f"altcha:used:{solution_hash}",
    "1",  
    nx=True,
    ex=600,  # 10 minutes, safely longer than the challenge TTL
)
if not is_first_use:
    raise HTTPException(400, "captcha already used")

An in-memory dict won't survive a deploy or scale across worker processes. Redis works. Postgres works. Pick something durable, pick a TTL longer than your challenge expiry, and you're done.

We use a separate HMAC key per environment, so a leak in dev can't be used to forge prod challenges. Same reasoning as keeping your test Stripe keys separate from your live keys.

When Altcha is the wrong call

We want to be honest about the limits, because they're real.

You're being actively attacked by a sophisticated bot operator. A real bot farm with cloud capacity can absorb proof-of-work costs at the bot's marginal cost of CPU. PoW raises the floor; it doesn't put a ceiling on a determined attacker. If you've ever had to pull pricing data off your site after a competitor scrape, you want behavioral ML, not a math puzzle. Altcha also supports Argon2id and Scrypt as memory-hard alternatives to PBKDF2, which resist GPU and ASIC acceleration and narrow the gap between consumer devices and bot farms; not a silver bullet, but worth knowing.

Your users are on very low-end devices. A one-second solve on a modern laptop can become a four-second solve on a five-year-old budget phone. If your audience is consumer mobile in developing markets, benchmark before shipping.

You can't run a Redis (or equivalent) for replay protection. A captcha without single-use enforcement is theater. If your hosting tier doesn't let you add a key-value store, fix that first, then come back.

For everything else (the long tail of SaaS signup forms, internal admin tools, contact forms, comment sections, account recovery flows), Altcha is the better default than reCAPTCHA in 2026.

FAQ

Is Altcha actually free?
Yes. It's MIT-licensed open source. The library is at github.com/altcha-org/altcha. The cost is the CPU spent on the verifying server (negligible) and the client-side compute (about a second of one core, once per submission).

Do I need to run a separate Altcha server?
No. Altcha is a protocol plus a small client library. You add two endpoints to your existing backend: one to mint challenges, one to verify them. There's no Altcha-the-service unless you opt into their managed offering.

Does Altcha work without JavaScript?
The default flow needs JavaScript (the Web Worker is where the proof-of-work runs). Altcha also supports a server-side mode where a pre-computed challenge can be verified at form-submit time, useful for accessibility tooling. Most setups won't need it.

Will switching from reCAPTCHA to Altcha break my form analytics?
Only if you were using reCAPTCHA's "human score" as a continuous signal in your analytics. If it was a binary pass/fail gating form submission, the switch is transparent.

Can I use Altcha on a static site?
You need somewhere to mint and verify challenges. A serverless function counts. A small serverless function handles this in about 30 lines of Python.

Closing

Captcha is one of those problems that looks solved until you read the privacy policy. Most teams pick reCAPTCHA because it's the default, not because they evaluated it. If you're an EU business, you almost certainly didn't evaluate it. Your DPO will, eventually, and the conversation is going to be uncomfortable.

We chose Altcha because it was the only option that kept the entire flow on our origin. You can run the same thing on whatever backend you already have. It's a couple of hundred lines of code and one Redis key prefix.

If you also care about which other US services your stack quietly depends on, the Vercel April 2026 breach checklist is a useful companion read.

What are managed sandboxes for AI agents?

Stefan Iancu — Tue, 26 May 2026 06:00:00 +0000

Ask an AI agent to "figure out why this script is slow" and it will. It writes code, installs three packages you've never heard of, runs them, maybe shells out to git to check something. The question is where all that runs. If the answer is "your laptop," you've handed a language model write access to your filesystem.

A managed sandbox for AI agents is the fix. It's a throwaway computer your agent gets, does whatever it wants inside, and hands back. "Managed" means you don't run it - one API call and it exists, one call and it's gone. That's the whole idea. The rest of this post is what that actually means, with real code.

A sandbox is just a throwaway computer

Strip away the jargon and a sandbox is a small, isolated computer that exists for a few seconds or a few minutes and then disappears. Your agent gets to be reckless inside it. It can rm -rf the wrong directory, install a broken package, run an infinite loop - and the worst case is "that sandbox crashed," not "my git history is gone."

Here's the entire lifecycle with the orkestr Python SDK:

from orkestr import Sandbox

with Sandbox.create(template="python-3.12") as sbx:
    sbx.files.write("/workspace/main.py", "print(sum(range(1_000_000)))")
    result = sbx.exec("python /workspace/main.py")
    print(result.stdout)        # 499999500000
    print(result.duration_ms)   # ~120

Create it, write a file, run a command, read the output. The with block terminates the sandbox when you leave it - even if your code throws halfway through. No leftover process, no lingering bill.

That's it. If your agent can call a function, it can use a sandbox.

The "managed" part means you run nothing

Plenty of teams build their own version of this. They spin up a VM, install Docker, write a queue, handle cleanup, patch the host, watch it 24/7. That's a real project, and it's not the project you actually wanted to ship.

"Managed" means that whole layer is gone. You call POST /v1/sandboxes, you get back a sandbox ID, you use it. No host to patch, no capacity to plan, no cleanup cron. The sandbox boots from a warm pool in under 30ms, and a cold boot is around 150ms - fast enough that your agent doesn't wait on it.

There are four templates to start from:

Template	What you get
`python-3.12`	CPython 3.12 with pip and common libs
`python-3.12-bare`	CPython 3.12 only, faster start
`node-22`	Node 22 with npm
`ubuntu-24.04`	A minimal Ubuntu shell

Pick one at create time. The sandbox comes up with that runtime already installed.

It can't reach anything it shouldn't

Here's the part that matters once an LLM is generating the commands. A sandbox isn't useful if it can quietly POST your data to an address the model invented. So network access is a setting you choose, not a default you inherit.

# no internet at all - the safe default for code you haven't read
sbx = Sandbox.create(template="python-3.12", network="off")

# allowlist - pip and npm work, random domains don't
sbx = Sandbox.create(template="python-3.12", network="restricted")

Three modes. off means no egress - nothing leaves the box. restricted routes traffic through an allowlisting proxy: the sandbox can reach package registries, GitHub, and the major LLM APIs, and that's the list. Your agent can pip install pandas; it can't connect to a host it made up. open is full egress, and it's gated behind a verified payment method on purpose.

Each sandbox is also isolated from every other sandbox. Two agents running on the same physical machine can't see each other, can't reach each other, can't even tell the other one exists. The boundary is the hardware, not a setting the kernel decides to honor.

It can pause mid-thought

Agent sessions aren't always a tidy ten seconds. Sometimes an agent does some work, waits on a human to approve a step, then continues an hour later. You don't want to pay for an idle VM during that hour, and you don't want to lose the agent's working state either.

So a sandbox can be frozen and thawed:

sbx = Sandbox.create(template="node-22")
# ... agent does some work, then hits a checkpoint ...

snapshot_id = sbx.pause()   # frozen to disk, not billed for compute

# an hour later, maybe from a completely different process:
sbx = Sandbox.resume(snapshot_id)

pause() snapshots the entire machine - memory, filesystem, running processes - and stops the clock. resume() brings it back exactly where it was. The agent doesn't know any time passed.

"Isn't this just a Docker container?"

Fair question, and the honest answer is: no, and the difference is the whole point.

A container shares the host's kernel. That's fine when you trust the code - it's how most of the internet runs. But the moment the code is something an LLM wrote thirty seconds ago and nobody reviewed, sharing a kernel with the host and with every other tenant becomes an uncomfortable bet.

Each orkestr sandbox is a real virtual machine. It boots its own kernel, mounts its own filesystem, and runs in its own slice of hardware. A bad command inside the sandbox stays inside the sandbox - there's no shared kernel for it to climb through. You get the disposability of a container with an isolation boundary that holds up when the code is genuinely untrusted.

What managed sandboxes for AI agents cost

Pay-as-you-go on active vCPU and RAM, billed per second. No per-invocation tax, no minimum, no monthly seat. A quick one-shot call costs a fraction of a cent, and a paused sandbox stops the compute clock until you resume it.

How many sandboxes you can run at once depends on your plan - 1 at a time on the free Starter tier, 5 on Pro, 15 on Team. Sandboxes are in private beta, so the full per-second rates aren't public yet - they land when the beta opens.

Handing it to your agent

You don't have to wire any of this up by hand. There's an MCP server - point Claude Code, Cursor, or any MCP client at /api/sandboxes/mcp and the agent gets tools directly: create_sandbox, run_shell, run_code, write_file, read_file, pause_sandbox, terminate_sandbox. The agent calls them like any other tool. No glue code.

The plain REST API also works as a configured sandbox provider for Claude Managed Agents, so you can keep the orchestration on Anthropic's side and run the actual tool execution on EU hardware.

When to actually reach for a sandbox

Sandboxes aren't a replacement for a normal dev environment. They're for a specific shape of problem - mostly "I'm about to run something I don't want on my machine." Six places they earn their keep.

Running model-generated code. The obvious one. Your agent writes a script and you want to actually run it to see if it works, not just stare at the diff. A sandbox is what turns "the agent suggested a fix" into "the agent shipped a fix." Worst case is the VM is gone.

Touching files you don't trust. A user uploads a CSV. A scraper dumps JSON. A teammate shares a notebook from somewhere. You want pandas on it, but you don't want a Zip-slip surprise on your filesystem. Open it in a sandbox, do the analysis there, return summaries.

A real Linux box from macOS or Windows. You're on a Mac. The thing you're testing is Linux-only - a Dockerfile, a glibc bug, a systemd unit. One API call gets you a Linux userland with the right architecture and none of the Docker Desktop dance.

Parallel experiments. Try three fixes at once. Benchmark four configs. Build against five Python versions. Agents that fan out across sandboxes don't fight over ports, lockfiles, or PATH. Each one starts clean.

Context-window discipline. This one is the subtle agent-design win. If your agent reads a 50,000-row CSV into the conversation, it just burned thousands of tokens on data the model doesn't need to see. If the agent works on it inside a sandbox and returns df.describe() or a chart, the model sees the conclusion, not the corpus. The sandbox holds the data; the conversation holds the answer.

Sensitive intermediate state. Generating credentials, decrypting a file, processing PII for a one-shot calculation. A terminated sandbox is gone - no swap file, no shell history, no /tmp for the next process to read.

The other half of the rule: sandboxes are the wrong tool when the working directory is the point. Editing your repo, running your own test suite, iterating on a feature branch - that all belongs on your machine. The sandbox is for code whose provenance you're not sure of, or an environment that needs to be disposable. If neither applies, you're paying latency for no reason.

The short version

A managed sandbox for AI agents is a disposable, isolated computer your agent can break without consequences - and "managed" means you get it from an API instead of building and babysitting the infrastructure yourself. Network access is something you choose. State can be paused and resumed. The isolation boundary is a real VM, not a shared kernel.

If your agent runs code - and most useful agents do - it should run that code somewhere that isn't your laptop or your production box. That's the whole job a sandbox does.

FAQ

What's the difference between a sandbox and a container?
A container shares the host's kernel; a sandbox VM brings its own. For trusted code that distinction rarely matters. For code an LLM just generated and nobody reviewed, the VM boundary is what keeps a bad command from reaching the host or another tenant.

Where does my agent's code actually run?
On dedicated hardware in the EU - Germany and Finland. Sandbox snapshots, environment variables, and runtime memory stay in the EU. For an EU company sending agent-generated code somewhere, that removes a data-transfer conversation. There's more on the EU angle here.

What happens if my agent forgets to clean up?
Every sandbox has a timeout_seconds (default 600) and auto-terminates when it's hit, so a crashed or forgetful caller can't leave a VM running forever. The SDK's with block also terminates the sandbox the moment you leave it.

Can I run a server inside a sandbox?
Not in the current beta - sandboxes are for running commands and code, not for hosting inbound services. If you want a long-lived app with a public URL, that's a regular orkestr deployment, not a sandbox.

How do I get access?
Managed sandboxes are in private beta. The waitlist is at orkestr.eu/sandboxes - it asks what you're building so we can triage who gets in each week.

EU managed sandboxes for AI agents, in private beta

Stefan Iancu — Tue, 19 May 2026 17:19:41 +0000

Your agent suggested rm -rf node_modules && rm -rf .git to fix a build error. You laughed, but only because you weren't running it. The thing about agent-generated shell commands is that they look reasonable until they don't, and most of them shouldn't run on your laptop or your production box - they should run inside something disposable, where the worst case is "the sandbox crashes" and not "I'm git-forensicing my own repo on a Friday night."

So we built managed sandboxes for AI agents. Private beta opening, waitlist live today at orkestr.eu/sandboxes. EU-hosted.

What this is

An HTTP API. Your agent calls POST /v1/sandboxes, gets back a fresh sandbox ID, then calls /exec to run shell commands, /files to read or write files, /pause and /resume to snapshot a session and bring it back later. When the agent's done, it calls DELETE and the whole thing - kernel, filesystem, processes - is gone.

Each sandbox is a dedicated VM. Not a container. Not a v8 isolate. Each one boots its own kernel, mounts its own rootfs, and lives in its own slice of hardware. Cold start is around 150ms; from a warm pool, under 30ms. When two agents are running in two sandboxes on the same physical host, they cannot reach each other - the boundary is hardware, not a namespace the kernel decides to trust.

Why an EU sandbox, now

Anthropic shipped Managed Agents, which lets Claude orchestrate an agent loop while tool execution happens in a sandbox provider you configure. The launch listed four supported providers: Cloudflare, Daytona, Modal, Vercel. All four are headquartered in the US.

That's a problem if you're an EU company sending agent-generated code somewhere. Standard Contractual Clauses cover transfers in principle, but if you're a Berlin fintech or a Paris insurance startup or a German healthcare company explaining to a procurement team why your agent's working data is processed by a US entity, you have a real conversation ahead of you. The EU sandbox alternative had to exist; we built ours.

So we did. The orkestr legal entity is in the EU. The hardware is in the EU. Your sandbox snapshots, environment variables, and runtime memory never leave the EU. GDPR DPA on request, signed by the same company that runs the runtime - not a US parent's subsidiary three layers down.

How it fits next to what's out there

If you've used E2B, Daytona, Modal sandboxes, or Cloudflare Sandboxes, the shape is familiar: REST API, Python and JS SDKs, exec / files / snapshot primitives. Here's what the Python SDK looks like:

from orkestr import Sandbox

with Sandbox.create(template="python-3.12") as sbx:
    sbx.files.write("/workspace/main.py", "print(sum(range(1_000_000)))")
    result = sbx.exec("python /workspace/main.py")
    print(result.stdout)  # 499999500000

Long-running agent sessions can pause and resume across requests, even across workers:

sbx = Sandbox.create(template="node-22", network="restricted")
snapshot_id = sbx.pause()
# ...minutes or hours later, from any process:
sbx = Sandbox.resume(snapshot_id)

There's also an MCP server you can drop into Claude Code or Cursor, and the REST API works fine as a configured sandbox provider for Claude Managed Agents. If your agent can call a tool, it can call this.

What's in the beta

Four templates at launch: python-3.12, python-3.12-bare, node-22, ubuntu-24.04. Each sandbox sized at 1 vCPU and 1 GB of RAM by default; quick one-shot calls cost fractions of a cent. Three network modes: off (no egress, the safe default for LLM-generated code), restricted (allowlist for package registries and common APIs), and open (full egress, gated behind verified payment).

Snapshots are native. Resuming on the same host is under half a second; cross-host is a few seconds because the memory file has to fly between data centres.

The compute runs on dedicated bare-metal hardware in Germany and Finland. Hardware virtualisation on every sandbox, no exceptions. Containers are fine for trusted workloads, but the moment an LLM is generating shell commands you haven't seen yet, sharing the host kernel becomes an awkward conversation. We didn't want to have it.

What's missing in private beta

The honest list:

GPU sandboxes. Not in v1. The CPU product has to work first.
Persistent volumes across sandbox lifetimes. Use pause/resume for now.
Custom Docker images as templates. Coming.
Multi-region routing. Two regions are live; we do not auto-route yet.
Detailed per-sandbox observability for end users. Building.

If you hit something not on this list that feels broken, it's probably a bug, so please tell us.

Pricing, briefly

Per-second CPU and RAM, no minimums, no per-invocation tax. We're keeping the full price list off the page until the first ten design partners have run real workloads against it. The numbers will move once we see what real usage looks like, and we'd rather quote the final price than walk one back.

The catch (because there's always one)

We're letting a small group in each week. The waitlist asks what you're building and what volume you're expecting, which is how we're triaging. Design partners get a discount on the first three months once paid usage opens, and a direct line to us for SDK feedback.

If you've been waiting for an EU sandbox for whatever agent you're building, the waitlist is here. If you have questions before signing up, email me (stefan at orkestr dot eu). I read everything.

Team workspaces on orkestr, and the ownership-transfer problem

Stefan Iancu — Mon, 18 May 2026 13:10:00 +0000

Introducing the Team Plan on orkestr

Imagine this scenario: You signed up for a Team plan a year ago. Your card is on file. You hired two engineers, invited them, and they've shipped most of the production work since. Now, you're leaving the company.

On most SaaS platforms, this is the moment you have to open a support ticket:

"Hi, can the new tech lead take over the subscription? Also all 12 projects. Also the domains. Also the audit log." Three business days later, you get an email asking for "verification" of something.

The Team plan launched on orkestr today. The entire flow is built right into the dashboard, and an ownership transfer takes about 90 seconds end-to-end.

Here is what is shipping today, and why building it was harder than it looks.

What Ships Today

Explicit Team Workspaces: Create a team, invite members by email, and switch workspaces from the top bar. Personal projects stay personal; team projects are visible to the team.
Shared Plan Budgets: Your Team plan's 15-project allowance is shared across your personal workspace and the team. The team owner's plan applies to team projects automatically.
Role-Aware Features: Members can see who created each project. To protect infrastructure, members cannot delete team projects—only the owner can. Additionally, the activity feed shows team-tagged actions to all members.
Seamless Ownership Transfer: If the owner wants out, they can hand the team (and every project and function inside it) to another member atomically. This requires a quick 1 EUR card verification from the new owner. The old owner's subscription gets canceled, and the new owner's billing cycle seamlessly picks up on the original renewal date.

Pricing: Team is available for 29.99 EUR/month or 299 EUR/year via the Pricing Page. It features the same EU-hosted infrastructure as every other plan, with no US data transfers.

The Workspace Model

The word "workspace" is heavily overloaded in SaaS, so it's worth specifying how it works here.

orkestr features exactly two workspace contexts: Personal and Team. An early draft included a third context called "All Workspaces"—a unified dashboard showing everything across every team you are in. After testing it on staging for a week, it was completely ripped out. It made security scoping invisible, and data scoping is a detail that should be explicit, not implicit.

The active workspace is now part of every backend request. If you are a member of a team and you open the projects page, you will not see the owner's untagged personal projects. This isn't hidden by the UI; the backend simply never returns them.

Expanding Scope for Plan Limits

The one place where scope expands automatically is plan limits. A project's plan is tied to whoever owns it. If you are on the free tier but working on a project within a paid Team workspace, you get full Team-plan limits on that project:

Rollbacks
Custom domains
Expanded CPU and memory budgets
IP allowlists

You won't hit any "upgrade to Pro" walls inside a team that is already being paid for.

Shared Budgets and Role-Aware Counts

The 15-project limit on the Team plan is a single budget split across both personal and team contexts.

If you (the owner) have 5 personal projects and your team has 8 team projects, you have used 13 of your 15 allowed projects. However, your team members will only see "8 of 15" on their dashboard. Their personal projects do not count against the team's budget, and they shouldn't see how many personal projects you hold. Even leaking the raw count feels like a privacy violation.


Total Team Budget: 15 Projects
├── Owner's View:   5 Personal + 8 Team = 13/15 Used
└── Member's View:  8 Team Projects     =  8/15 Used

This is the kind of detail that nobody notices when it's right, and everyone notices when it's wrong. The same logic applies to the activity feed: members see team-tagged actions from everyone plus their own personal actions, but never the owner's personal actions. The same goes for domains, add-ons, and deployments.

Solving the Invite Flow & Email Mismatch

Invites are entirely email-based. The owner enters an email, the system creates a TeamInvite row, and the invitee gets a link. Standard practice.

However, a common, annoying edge case occurs when an invitee already has an orkestr account, but under a different email. For example, they signed up with firstname@gmail.com for personal use, but you invited their work email: firstname@company.com. Most platforms either silently match the accounts (which is dangerous, as emails are not identity) or hard-fail and tell the owner to try again.

orkestr handles this gracefully. The acceptance page displays:

"This invite was sent to firstname@company.com. Your account email is firstname@gmail.com. Are these the same person?"

If the invitee confirms, the system logs both emails on the membership row and grants access. If they say no, the invite stays open for whoever actually controls that email address. This tiny UX detail eliminated roughly half of the anticipated support tickets.

Re-engineering Ownership Transfer

Until recently, if a Team-plan owner wanted to leave a team, they had one option: remove every member, delete every team project, cancel their subscription, and let the data evaporate. That isn’t an ownership transfer; that's burning down the office and leaving.

Here is how the new, 90-second automated flow works:

Owner Requests Transfer: The current owner selects a team member and checks a consent box acknowledging they will lose access to all team projects and functions.
Target Notified: If the target teammate isn't on a Team plan yet, they are prompted to subscribe. A team cannot be handed over to an account whose plan limits cannot support the existing resources.
Target Pays 1 EUR: This is a Mollie card verification, not a real charge. It serves two purposes: it proves the new card is valid before handing over a subscription, and it satisfies EU consumer protection rules requiring an explicit, attributed action before initiating a recurring charge.
Atomic Swap: Once Mollie confirms the verification, a single database transaction reassigns the team, every project, and every function in one go. Either every write succeeds, or the entire transaction rolls back.
Subscription Handover: The new owner's billing cycle starts exactly on the day the old owner's subscription would have renewed. The old owner's subscription is canceled, and the 1 EUR verification fee is refunded.

Aligning the start date to the original renewal date prevents both parties from double-paying or losing paid days, completely eliminating a common customer service trap.

What’s Not in This Release

To be completely transparent, a few features didn't make the cut for today's launch:

No Automatic Expiry on Pending Transfers: Right now, transfer requests sit open indefinitely until someone explicitly cancels or accepts them. A 7-day default expiration will be added soon.
No Multi-Owner Teams: There is a strict limit of one owner per team. Co-ownership introduces entirely different database invariants and security complexities, and we didn't want to ship a half-baked version of it.

If you’ve been waiting for team collaboration features, you can get started right now at orkestr.eu/pricing. If you’re already on a Pro plan and want to bring your engineers onboard, you can find the upgrade toggle directly in your workspace settings.

About Vercel's April 2026 breach: your checklist

Stefan Iancu — Tue, 21 Apr 2026 04:00:00 +0000

Vercel published a security bulletin on April 19 confirming a breach of its internal systems. On April 20, CEO Guillermo Rauch followed up with the root cause: a Vercel employee used a third-party AI tool called Context.ai. Well, this tool got breached. The attacker pivoted from there into the employee's Vercel Google Workspace account, and from there into Vercel environments and environment variables that weren't marked as "sensitive." Is this the customer fault? (jk)

Vercel says a "limited subset" of customers were directly impacted and have been contacted. They also say Next.js, Turbopack, and their other open-source projects have been analyzed and are believed safe.

That's the facts. Now the honest part: if you deploy on Vercel, don't wait for an email. Rotate first, ask questions later.

The Vercel breach checklist

1. Rotate every environment variable that wasn't marked as "sensitive" in Vercel.

Do this first if you do nothing else. Vercel's sensitive environment variable feature encrypts values at rest and hides them from the dashboard after creation. Everything else - the default - was readable by anyone with access to that employee's Google Workspace session. Assume those values leaked. Payment processor keys, database URLs, auth secrets, cloud provider keys, admin API tokens to third-party SaaS. Rotate all of it.

2. Review your GitHub organization audit log.

If your Vercel account is connected to GitHub (it almost certainly is), pull the audit log for April 1 through today. Look for unexpected OAuth grants, new deploy keys, workflow edits, branch protection changes, or pushes from unusual IPs. The community-maintained IR playbook has a solid filter list.

3. If you use the Vercel ↔ Linear integration, check Linear's audit log too.

Linear issues are where people paste stack traces, database URLs, and occasionally plaintext secrets while debugging. The integration has read access to issues. Workspace settings → Security → Audit log.

4. Audit any npm package you publish from a Vercel-connected workflow.

Vercel says their own packages are clean. That's their release path, not yours. If you use Vercel's build environment to run npm publish or push to a registry, treat any package published in the exposure window as suspect until you've diffed it.

5. Don't skip the boring step: inventory your exposure.

For every Vercel team you control, list the projects, the connected Git orgs, the integrations, and the humans with access. Half the pain of incident response is discovering on day three that there was a second team nobody remembered.

The part nobody wants to talk about

The attack didn't start at Vercel. It started at Context.ai, an AI tool a single employee had connected to their work account. They also posted about it. This is how modern breaches happen. You don't get popped through your WAF. You get popped because someone on your team authorized an OAuth grant to a YC-stage AI startup that had one security engineer and a Notion doc for an incident response plan.

There's no EU-vs-US angle here. European PaaS vendors have employees too. Employees use AI tools. The same thing could happen to Scalingo, Clever Cloud, or us at orkestr.

What matters is:

How much blast radius does one compromised employee account actually have?
Are production secrets readable from a dashboard, or are they sealed?
How fast does the vendor tell you, and how specifically?

Vercel's bulletin on April 19 was terse to the point of unhelpful. The detail came from press reporting and a follow-up from the CEO a day later. "We recommend reviewing environment variables" isn't incident communication. It's a legal posture. You should expect better from anyone you hand your deploy keys to — us included.

Whatever platform you're on: rotate your secrets today. Mark them sensitive. Cut the SaaS integrations you're not using. And write down who on your team has production access, because there will be a next one.