Oct 28, 2026Replit’s Architecture Behind Secure Agent Work
Empower businesses to do more ambitious work with AI in Replit’s Agent Habitat, backed by the security and governance they need.
Oct 16, 2026Bring Your Own Cloud to Replit
Enterprise isolation and control. The same simple experience for users.
Mar 18, 2024More Reliable Connections to Your Repls
At Replit, session success rate is one of our service level objectives (SLOs). This means that any legitimate incoming request from a client should always be successfully connected to its target Repl. Failure to do so is a bad user experience. To abstract away intermittent infrastructure failures when you connect to a Repl, we use a reverse WebSocket proxy between the user’s client and the remote VM hosting Conman, our container manager that runs all Repls in a container. The high-level view of this proxying looks something like this: In the above diagram, Regional Goval Cluster represents our backend, which is sharded per region for scale and to prevent cross-region latency and egress costs. You can read more about it in this blog post. The diagram illustrates that the reverse WebSocket proxy can attempt a retry if any failures occur during the connection setup with Conman. The proxy is alive throughout the connection and transfers data back and forth between the client and the user’s Repl. The problem Everything seems architecturally sound here, so what was the problem? Conman, technically our container manager and responsible for running Repls in containers on GCE VMs, also doubled up as our reverse WebSocket proxy. Here’s what our architecture and overall flow used to look like:
Feb 14, 2024Sharding Infrastructure: The Regional Goval Project
The main task of the infrastructure team at Replit is to ensure your Repls run well. A Repl can be thought of as a Linux container with a filesystem. To run Repls, we need to take care of several pieces of infrastructure: Virtual machines to run Repl containers on Databases to keep track of container and VM states Cloud storage to store Repl contents Reverse proxies to route HTTP requests
- May 19, 2023
May 18 Replit downtime
Yesterday, we had a period of about 2h from 11:45 to 13:56 (Pacific Time) in which all users were unable to access their Repls through the site. We have addressed the root cause, and the system is now operating normally. We know a two-hour downtime is not acceptable for you or your users. This post summarizes what happened and what we're doing to improve Replit so that this does not happen again. Technical details Here is the timeline of what happened, all times in Pacific Time: In 2021, we changed the way that configuration is pushed to the VMs that run Repls and streamlined multiple kinds of configurations. During this migration, a latent bug that we had not hit was introduced. When we tried to see if a configuration kind had been updated, we acquired a Golang RwMutex for reading, but if there was not a handler for that configuration kind, the read-lock would not be released. Golang's RwMutex are write-preferring, so acquiring multiple read-locks is allowed as long as there are no goroutines attempting to acquire a write-lock. When that happens, it will cause any future read-locks to block. On May 16, 2023,we introduced a new configuration kind, but we did not add a handler, which means that from this point on we were leaking read-locks, but the system was able to make progress.
Apr 11, 2023Replit Deployments - the fastest way from idea → production
After a 5 year hosting beta, we're ready to deploy. Introducing Replit Deployments Today we’re releasing Replit Deployments, the fastest way to go from idea to production in any language. It’s a ground up rebuild of our application hosting infrastructure. Here’s a list of features we’re releasing today: Your hosted VM will rarely restart, keeping your app running and stable. You’re Always On by default. No need to run pingers or pay extra. Say goodbye to the “Repl Waking” screen because your VM doesn’t go to sleep. Isolated VM resources for your app will give you improved security and performance.
Nov 11, 2022See Your Currently Running Repls
Have you ever wondered which of your repls are running at a given time? Do you know which ones are currently serving traffic, and which ones need to be woken up? Do you wish you had more visibility into when your repls have stopped in the past and when they've been restarted? If any of the above describe you, we have just launched a new feature made especially for you: the Repl Status Manager. To use it, go to the Status tab on the My Repls page. When you get there, you'll see a list of all the repls you've ever run in your account, sorted by recent activity -- including the ones that are currently running!
- Oct 12, 2022
Analytics For Every Repl
Web hosting on Replit is simple yet effective. When you start a server in your repl, we automatically detect which port it opened on and provide a public endpoint for you to access it. In other words, every HTTP request that goes to a *.repl.co domain is reverse-proxied through our secure infrastructure. This lets us do some cool things that more basic hosting providers simply can't do. One of these is analytics for your website or API. Have you ever wondered how many people visited your web site, what browsers they used, and whether they had any issues? Now you can find out! As of today, web analytics on Replit is automatically available in every repl, without installing any third-party JavaScript packages. To access it, just add /analytics to the end of your repl's URL, such as https://replit.com/@user/slug/analytics after enabling the Explorer role on your account. Web Analytics Dashboard
Mar 30, 2022We Built a Search Engine
For the past few months, we have been building a Replit-native search engine. It is remarkably powerful, and we are really excited for you all to try it out. We believe that you should be able to find anything on Replit in less than 30 seconds. This might sound simple, but when you have 100 million+ Repls, it becomes complicated. :) When you search for something on Replit today, you'll see a page with relevant results from the following categories: Repls Templates Code (yes, code)
Oct 12, 2021Faster Nix Repl Startup
For the past few months we have been working on improving our Nix integration. Nix allows users to easily use over 80,000 Linux packages in a repl. Nix opens the door to many exciting tools and applications on the platform. Our goal is for every repl to be backed by Nix. Before we can do that, we need to ensure that the Nix experience is just as good, if not better, than our existing Polygott solution. If you've used a Nix repl, you may have noticed additional loading time when opening your repl. The console would show "Loading Nix environment..." and you'd have to wait for a few seconds. In some cases, you might have waited for tens of seconds. We care about making repls start up as fast as possible and this additional loading time wasn't acceptable. Through some additional caching, we have entirely removed this loading time on many Nix repls. Now, Nix repls will start up just as fast as Polygott-based repls. See below for a before and after demonstration. Before: After:
Sep 10, 2021Data Loss: a sad tale with a happy ending
Earlier this year, we discovered that we were losing data for some of our users. This manifested as either repls being completely empty after reloading, or some of the changes to files not being present after reloading. Obviously losing data is the worst we can do, so we had to fix this immediately. This blog post narrates the adventure of how we discovered this, how we fixed it, and the lessons we learned during the way. The discovery Throughout the year, we had had some worries about some theoretical cases in which users could lose data. We have had a few complaints from people that their code wasn't correctly saved, and since we weren't sure what caused them, we just tried to fix bugs here and there one at a time in an unstructured fashion. Around mid-July, we got an alarmingly large number of reports of people about their code not saving correctly in a short amount of time, ironically just after deploying one such fix. This meant two things: our intuition about folks losing data was correct, but the way we were fixing it was not! This led to the immediate discovery that there were months- or years-old bugs that were silently losing or corrupting data, and some of them turned out to be load-bearing bugs that couldn't be fixed in isolation (since fixing them triggered other kinds of data loss). This made us start a much larger project to have better guarantees and incrementally fix things without regressions. Homer Simpson doing a dramatic impression of this whole situation
- Sep 1, 2021
Making Replit Faster for Everyone
Replit's mission is to make programming accessible and provide computer superpowers. To achieve that goal, repls need to be fast. To that end we've been working on a number of improvements in our infrastructure and code to unlock faster repls. We constantly analyze the speed of our clusters and identify areas of improvement. Here are a few examples. Editing Code Just Got Faster We split repls woken up by hosting (repl.co, custom domains) to different VMs than repls that you access in the workspace. This makes editing code and interacting with your repl in the workspace faster by ensuring your usage isn't competing with nearly as many other repls. For repls being actively edited in the workspace, we've seen an average 10-20% improvement in speed from this change. This applies across all subscription types including free users. More CPU For Your Repl
- Aug 5, 2021
Replit²
Replit has many use cases and features, but one that's less talked about is its ability to serve as a secure compute environment for specialized apps. What if you want to build some tool that will generate code, then execute it for your users? Or maybe you are building a specialized online IDE that injects code for users, then executes the bundle? With Replit, you can start building those kinds of applications quickly without having to focus on building a fast and secure backend. Build the frontend, we'll provide the compute power. That's a great promise, but it's not one that is fully documented. Well, now that is a thing of the past! Let's explore how Replit can serve as your compute backend by building a very basic Replit clone. UPDATE 2021-08-16: Please check the section on Security at the end of this post, more details were added and the post was clarified thanks to the help of @AmazingMech2418. Building a compute node A compute node is a single unit (usually a single server, VM, container, or application) of computing power than can execute work. In our case, a compute node will be a single Repl that can execute arbitrary code using an API. We'll be using the Koa.js framework and python in this post. Let's start by creating a new Nix repl. Why Nix in particular? Nix allows us to install any package that can be found on the official Nix package registry. This give us the ability to install any language interpreter or binary we want, provided said language is able to execute arbitrary code. With minimal work, we'll be able to implement multiple languages in our compute backend and execute them through our API.
- Jun 24, 2021
Dynamic version for Nix derivations
UPDATE - 05/07/2021 Thanks to Travis Cardwell for letting us know that Nix requires the version part of the derivation name to start with a digit. The post has been upated from its original version to include this requirement. When you open a repl, we link it to a Docker container in the cloud. As we've started supporting more and more languages over the years, the size of that Docker image has exploded in size. It can take us up to a week to safely deploy! Any update, no matter the size, to our tooling can't be shipped to our users as fast as we'd like. This is where our migration to Nix comes in. We are now building these tools in our CI pipelines as Nix packages. We can reduce the size of our image to its minimum and provide all our tools and languages through Nix, on demand. One drawback of Nix for us is the need to specify the version in the derivation code (Like you would do in the package.json in NPM for example), rather than rely on image tagging. Before we could move forward, we had to solve one of the harder problems in computer science: versioning. We settled on using the commit short sha (first 7 characters of a commit's ID) as the version for our tools. However, we needed to go edit the default.nix file manually in the tool's repository every time we needed to publish a version. This wasn't providing us with the speed and flexibility we wanted, and we wondered if it was possible to generate the version automatically. After all, Nix is a fully fledged programming language, so that should be doable? It is, but it was not as easy as we thought. Starting with a Nix package One great thing about Nix is that its entire library of standard packages is available in a very easy to parse GitHub repository. A quick search led me to this package in particular. That code does almost the same thing we're hoping to do: call a runCommand function and execute git rev-parse --short there. With this in hand, I trimmed the code and wrote a quick function to get the short sha.
May 24, 2021How we went from supporting 50 languages to all of them
At Replit, we want to give our users the most powerful, flexible, and easy-to-get-started coding environment. However, it has been limiting because we only support a fixed set of languages and OS packages, some of which are outdated. Ideally, users should be able to use any language and install any package with minimal fuss. That's why today, we're announcing that we've incorporated Nix in our infrastructure to give users access to over 30,000 OS packages instantly. The environment repls run in has long been a static world. We build a pre-baked OS image to fit all our languages. This gives us a lot of leeway to make repls super fast, but the underlying operating system repls run in is completely immutable. To remedy the situation we've been maintaining an ever growing OS image, if users can't install any packages we'll just install every package! As awesome as this sounds it has become a huge burden to maintain. Every new package creates a new exciting way things can break. Over time, it became clear that maintaining a single, massive docker image was not sustainable. We came across Nix which is a declarative, reproducable OS package manager. Due to Nix's design its package store is highly cacheable and allows for building environments in a composable way. Using the Nix programming language you can specify the dependencies for your development environment and Nix will build the environment for you. We believe this is a great fit for Replit as it allows our users to build endless combinations of development environments without us having to maintain a monolithic docker image. With Nix on Replit, see how easily you can create a Zig environment in a few seconds. We create a replit.nix file to tell the repl which Nix packages should be available when we run. Then we use .replit to control what the run button does. And voila we have a new language: How it works