Breaking the Sandbox: Why ZITADEL Actions v2 Shifts to Cloud-Native Orchestration
Founder and CEO
- Breaking the Sandbox: Why ZITADEL Actions v2 Shifts to Cloud-Native Orchestration
Breaking the Sandbox: Why ZITADEL Actions v2 Shifts to Cloud-Native Orchestration
In the world of Identity and Access Management (IAM), "out of the box" rarely fits perfectly. Every business has that one unique requirement—a specific fraud check, a legacy database lookup, or a complex enrichment of a user token.
At ZITADEL, we solved this early on with Actions v1, a feature that allowed you to execute custom javascript directly into our authentication pipeline. It was fast, simple, and solved immediate problems.
But as our community grew and the architectures we supported became more complex, we realized that running code inside the identity server was a constraint we needed to break. We hit a ceiling where "simple" began to compete with "scalable."
We are moving from "embedded extensions" to "programmable, event-driven webhooks." This post explains the reasoning behind that architectural shift and why it matters for the future of your stack.
The Architectural Shift: From Monolith to Nervous System
When we built Actions v1, we prioritized locality using an embedded JavaScript runtime. It was convenient, but it coupled your logic to our release cycle and our infrastructure.
The move to Actions v2 is a move to a more mature Cloud-Native Orchestration. We believe Identity shouldn't be a black box; it should be the nervous system of your architecture, sending signals and delegating decisions to the parts of your stack that know best.
1. Bring Your Own Stack
We shouldn't force you to learn a proprietary dialect of JavaScript to secure your app.
The V2 Reality: If your billing logic is in Go, write your identity hooks in Go. If your fraud detection runs in Python, keep it there. By shifting to standard HTTP contracts, ZITADEL becomes a polyglot coordinator rather than a monolithic executor for your business extensions.
2. Production-Grade Reliability
Your identity platform is critical infrastructure. It deserves CI/CD, version control, and proper observability. The V2 Reality: Because V2 Actions are now web services, you can deploy them using the same pipelines as the rest of your fleet. You can run them locally, debug them in VS Code, and monitor them with Datadog or Prometheus. No more "testing in production."
3. Isolation & Scale
A custom script shouldn't have the power to crash your authentication server.
The V2 Reality: By decoupling execution, we ensure that the core ZITADEL service remains rock-solid. If your custom webhook hangs or times out, ZITADEL handles the failure gracefully (blocking or ignoring) without degrading the availability.
The New Patterns: What You Can Build
With this new architecture, you aren't just writing scripts; you are designing Identity Patterns. Here are the three ideas that you can build with actions V2:
A. The Policy Enforcer
- The Goal: Stop invalid requests before they are processed.
- The Pattern: ZITADEL pauses the authentication flow and sends the candidate data (e.g., a registration attempt) to your webhook.
- The Application: You can enforce governance rules that are specific to your business—like checking usernames against a reserved list, blocking high-risk IP ranges, or validating invitation codes against an external inventory system.
B. The Identity Enricher
- The Goal: Make the token smart by adding context from your ecosystem.
- The Pattern: Instead of synchronizing data into ZITADEL, you fetch it just in time. When a token is minted, ZITADEL asks your service for "Patches."
- The Application: Your webhook endpoint checks your CRM for the user's Subscription Plan and instructs ZITADEL to append a x-plan: enterprise claim to the token. The identity system remains the source of authentication, but your business logic remains the source of authorization.
C. The Immutable Auditor
- The Goal: Compliance and Observability without added latency.
- The Pattern: ZITADEL fires a "fire-and-forget" event to your webhook immediately after an action occurs.
- The Application: This is crucial for heavily regulated industries. You can stream every UserCreated or PasswordChanged event directly to your SIEM (Splunk, Sentinel) or trigger downstream provisioning workflows (like creating a Slack account) without slowing down the user's login experience.
The Developer Experience: Standards over Magic
The most visible part of this change is the removal of "Magic." We moved away from proprietary objects injected into a sandbox, towards standard web APIs.
Stability vs. Lock-in: Legacy providers like Keycloak use Service Provider Interfaces (SPIs) that force you to write Java and manage internal dependencies. Similarly, SaaS alternatives like Auth0 run your code in proprietary Node.js sandboxes, limiting you to supported runtime versions and npm packages. ZITADEL's V2 uses a clear, versioned HTTP contract. Your custom logic is decoupled from our internal architecture, meaning you can upgrade ZITADEL without refactoring your extensions.
| Feature | Actions V1 (Embedded) | Actions V2 (Webhooks) |
|---|---|---|
| Language | ECMAScript 5.1 (Proprietary) | Any (Go, Rust, TS, Python) |
| Debugging | console.log in ZITADEL logs | Local Debugger (VS Code, etc.) |
| Testing | Live Instance Required | Unit Tests (Mock JSON payloads) |
The Path Forward
We are committed to the "Road to 2026" vision: Making complex multi-tenancy simple, secure, and scalable. By moving to standard contracts and decoupled execution, we ensure you don't have to choose between speed and control. Your Identity infrastructure should be robust enough to scale indefinitely, yet flexible enough to evolve as fast as your application code.
Start Building
We have prepared some resource to help you implement these patterns in your preferred stack:
- Using Actions | ZITADEL Docs
- Code Examples: Cloudflare Workers Repository
- Docs: Migrating from V1 to V2
Don't build alone. If you are architecting a complex migration, join our Community Chat to discuss your strategy with our engineering team.