Background
For most of its history, Replit was a pure dev environment company – if you wanted to share an app with your friends, you had to share a development runtime. This led to a few problems, most notably that your app would break if you ever wanted to modify it while someone else was using it. This was the idea that led to Replit Deployments, a new way to share a production application directly from your development environment.
Architecture
Replit Deployments is built on the concept of making deployment intuitive without sacrificing power and customizability. At its core, a deployment in Replit encapsulates the production runtime environment, build configuration, and monitoring tools into a cohesive, user-friendly experience.
Deployments are integrated into Replit's Workspace (IDE), allowing users to deploy directly from their development environment. Users can configure environment variables, monitor resource usage, and roll back changes within the same interface they use to write code. Deployments automatically handle common tasks like setting up servers, managing containers, and provisioning resources, abstracting away the complexity behind a simple interface.
Surfaces
Deploying a project begins by clicking the Deploy button in the top right corner of the Workspace. This will open the Deployments tool, which shows you a number of top-level deployment architecture types for you to choose, along with Replit's recommendation.
Next, you can set up your deployment properties, such as build command, run command, machine power, and more, depending on which deployment type you just chose.
For Autoscale deployments (our serverless offering), I had to solve the tricky problem of making it easy to set a valid machine power configuration. Our underlying serverless provider only allowed certain amounts of vCPU power for a given amount of RAM, and vice versa. They communicate this difficult constraint across two separate docs pages, which makes it very hard to make sense of. I knew our users deserved better than that.
The solution I arrived at was a pair of sliders connected by a rope. When dragging one slider near the edge of the valid range (dictated by the other slider), the rope will turn blue to indicate something is about to happen. When you drag your slider outside the valid range, the other slider will jump to the next valid value. This way, the system is always in a valid state. In addition to designing this UI, I also built it on my own. The art direction was inspired by Cut The Rope.
After completing setup, your app will deploy to production.
The deployment overview is a timeline showing your current production deployment, all past deployments, and some affordances for redeploying or updating your produciton settings. It is meant to convey important app state of past, present, and future as clearly as possible.
When you redeploy your app from the Deployments tool or the button in the top right, the status of the ongoing deployment is shown in the timeline. The principle I felt was most important on this surface was keeping the time axis clear and consistent.
After launching Deployments, the main issue we found from both our app data and qualitative user feedback was that people had a hard time debugging their failed deployments. Upon reviewing our logs, it was clear that in the great majority of cases, failed deployments could be attributed to buggy code or incorrect deployment configuration (i.e. user error), but these sorts of issues are not always legible to our users, much less easily solveable.
I felt that the best solution was to clearly communicate the error and provide a short path to a fix. Fortunately, it was around this time that our AI platform was becoming fairly robust. I wanted to take this opportunity to add our first AI intervention that did not involve code generation – a failed build module that made fixes easy. It works as follows:
- The build fails, generating an error log
- The log is fed to LLM, which has context about your code base
- The LLM generates a solution to the error
- The LLM summarizes both the error and the solution
The resulting UI is a couplet that shows the summarized error with a summarized solution that you can apply with a click and redeploy.
This deployment debugging module increased the number of eventually successful deployments by 87% in the first 2 months, so I would call it a great success.
Beyond the overview, you can use the deployment observability tools to get an idea of your app's health and usage, or you can configure your deployment further by adding custom domains, modifying your machine power, or pausing/deleting your app.
