earlier this week, @Replit rolled out a minimal kernel to our shiny new microVMs. today, we discovered that the minimal kernel is immune to "pedit COW" a.k.a. CVE-2026-46331. the platform infrastructure team gets to not scramble to fix a kernel bug this weekend 🎉

the day has come: new Linux kernel vulnerability dropped and @Replit users were not affected, courtesy of the fact that we just migrated all projects to use MicroVMs powered by cloud-hypervisor.

it took at least... (counts)... _four_ major supply-chain attacks for the npm ecosystem to finally start implementing measures against this family of preventable issues. at last we're finally moving in the right direction! (also, Replit's default minimumReleaseAge saved us)

gente de cdmx, recomienden cafés buenos de por acá

last Saturday, @Replit was free for 24h. we had planned for 2-3x increase in traffic and were surprised by the level of turnout: ~4x at peak. despite that extra load, and thanks to some short-term interventions, we were able to give everyone that wanted to participate a good experience. super proud of the team for pulling this off!

any of you have implemented systems using cuelang.org/ , openpolicyagent.org/docs/pol… , or cedarpolicy.com/en at scale? send me a note please.

Security of the apps you build on Replit is one of the most important problems we work on. Established tech companies built up robust practices built around expert reviewers and internal infrastructure. AI and Cloud means we can bring this to everybody. Each day, we're going to get one step closer to bringing state of the art practices to every builder. Keep your eyes on this channel for the next couple of weeks...

No single layer is the whole story. Each one assumes the layer above it might fail. That's what defense in depth means, and it's the only way to earn the trust of teams that take security seriously.

Even though every layer of the system has been hardened to provide security robustness, security incidents can still happen. Sometimes, these incidents happen due to external influences or supply-chain attacks. At Replit, every single security incident is handled with urgency because users’ data is at stake. Trust is something that has to be earned over time, and can be easily lost by not going above and beyond. Every incident is also a learning opportunity: every root cause that we find becomes a hardening effort so that the incident itself no longer repeats itself, but also fix any adjacent problems that were surfaced by the incident, and tighten up defenses in other parts of the stack.

We have partnered with several companies over the years that provide penetration testing for both the Replit platform as well as the serving infrastructure that we use. @Hacker0x01 has managed our bug bounty program in addition to helping us do spot checks of new services just prior to releasing them. We also recently engaged with @trailofbits to do a much more in-depth assessment of several Replit services. We have also recently investing in AI red-teaming for our internal testing. Even though Replit doesn’t have access to Project Glasswing, we have seen great success with building an internal security-focused harness similar to red.anthropic.com/2026/zero-… that continuously scans our source code, prioritizes potential findings, and validates them before involving engineers to address them. This effort has also guided some architecture changes to reduce the attack surface area.

Once published, Replit applications run on @googlecloud infrastructure. We take a deliberately contrarian approach to tenant isolation compared to other providers: every single customer gets their own GCP Project, even free-tier users. This maximizes the isolation between deployments at the infrastructure level. Applications run in cloud.google.com/run with state-of-the-art sandboxing, and every deployment, regardless of tier, is protected by Google Cloud Armor for DDoS protection and Web Application Firewall (WAF) capabilities. This infrastructure was crucial in our mitigation of the React2Shell vulnerability (blog.replit.com/critical-sec…).

Before any application is published to production, Replit runs a full suite of security and privacy scans. We've deliberately built a scanning pipeline that goes beyond AI-powered analysis alone, since purely LLM-based safety programs have been shown to be insufficient for adequately protecting AI-built applications. Replit's security center uses a combination of rule-based SAST/SCA scanning and LLM reasoning (securing-ai-generated-code.r…). Rule-based scanning excels at finding CVEs and supply chain attacks like the Shai-Hulud npm worm (blog.replit.com/npm-supply-c…), while the recently-released Replit Security Agent (blog.replit.com/meet-replit-…) is better at finding architectural flaws and logic errors. We've also partnered with @semgrep to further augment the categories of vulnerabilities we can detect. hounddog.ai/ helps find any privacy issues too.

While the Agent is building code, Replit continuously evaluates (blog.replit.com/decision-tim…) the produced code to catch potential security issues, bugs, and architectural mistakes in real time. This follows the Shift Left (en.wikipedia.org/wiki/Shift-…) philosophy: identifying and addressing faults as early as possible in the development process, when they're cheapest and easiest to fix, rather than discovering them after deployment.

To prevent the Agent from making common mistakes when implementing authentication, Replit provides a turnkey auth solution (docs.replit.com/core-concept…) that removes whole families of bugs and exploits. This authentication layer powered by clerk.com/ is enterprise-grade and fully end-user customizable: applications inherit a battle-tested auth stack without the Agent having to implement one from scratch. You are still in control and can choose how it presents itself so that your brand is still well-represented.

For connectors, we're moving toward a model where application code never has access to passwords or secrets at all. Instead, connections are transparently proxied through a sidecar service with no persistent storage. This sidecar injects the necessary HTTPS Authorization headers on the fly, so that application code never handles the underlying credentials, even by accident. We apply the same technique to MCP integrations: the Agent never communicates directly with MCP servers. All traffic flows through a transparent proxy that adds OAuth headers without exposing them to the application context. In addition to protecting secrets, we scan MCP tool definitions and tool responses to detect and prevent several families of prompt injection attacks.

By default, applications on Replit cannot access data in other applications. Cross-application data access requires explicitly opting in through Connectors (blog.replit.com/connectors) or Data Connectors (blog.replit.com/data-connect…). Granting permissions is straightforward, but the default posture of no access means reduced data surface area and fewer accidental exposures.

Every filesystem at Replit is backed up at least daily (blog.replit.com/how-replit-m…). This same backup mechanism also protects development databases, providing a consistent recovery point for all user data. Beyond filesystem backups, every Replit application uses git as a normal part of Agent-driven development. But we go further: each sandbox runs a container sidecar with a full git remote that is append-only. Even if the .git directory inside your application is accidentally deleted, the complete history is always recoverable from the sidecar. This is an approach that helps recover development work even if the worst happens.

Replit provides isolation between development and production environments. This goes beyond the typical "separate compute" approach: we extend the same separation to the database layer. We implement forkable databases using the same snapshot technology that powers our filesystem storage. This means every application gets an independent development database that can be forked, rolled back, and iterated on without any risk to production data. The same technology scales to millions of databases and preserves every revision of the development database. This separation prevents a class of catastrophic accidents where a production database is accidentally modified during development, the kind of incident that has publicly affected even experienced founders.

Replit sandboxes use Determinate Nix as their package manager. This keeps the Nix installation and all third-party packages and dependencies in your application up to date and free of known vulnerable versions. Determinate handles the hard problem of ensuring that the software supply chain underneath your application is continuously patched.

Because Replit runs full cloud sandboxes, applications built on Replit naturally follow industry best practices: a separate frontend and backend. This structural separation makes Replit-built applications significantly more robust against the class of vulnerabilities that plague other vibe coding tools (nvd.nist.gov/vuln/detail/CVE…); tools that rely almost exclusively on Row Level Security for access control. To be clear: RLS is an excellent mechanism for defense in depth in PostgreSQL applications, and we use it ourselves internally. But RLS works best when paired with a proper backend that can perform authorization checks with full context, not as the sole access control layer sitting directly behind a client-side application.