Introducing Workflows

Szymon Kaliski

Szymon Kaliski

Devin Halladay

Devin Halladay

Jonathan Zhou

Jonathan Zhou

With Workflows, you can easily save your development processes and organize them as a sequence of Tasks. Instead of having to repetitively type commands into your shell and remember them, Workflows provide an intuitive interface to configure your frequently used commands and execute them with the click of a button.

Simplifying development with Workflows

Workflows give you the ability to better organize your project execution pipeline, while offering an accessible interface to reuse them. Using the Workflows pane, you can easily configure specific buttons to run specific commands, and even link multiple Workflows together in a chain. Instead of copy pasting "cd ./client && npm run dev && cd ../server && node server.js", you can define the procedure as a Workflow with multiple Tasks.

Let's see how it works with an example.

We can start by defining a Workflow to run only your frontend server:

Next, we can make a separate Workflow for running your backend:

If you want to start your full-stack project with one click, you can create another Workflow to start the two processes in parallel:

Running this Workflow would simultaneously start your frontend react website and your backend express server. Additionally, the outputs of the two processes remain isolated, making debugging easier.

See it in action:

Workflow Demo

Now you can run your frontend, backend, or full-stack app, each with the click of a button. If you want to change the default run button behavior to run one of your Workflows, it’s easy to configure:

Assigning a workflow as the run button

To learn more about configuring Workflows and its features, including automatic package installation and recursive command chaining, check out our Workflows documentation.

Building Workflows UI

The Run button is a hallmark of Replit’s simplicity and ease of use, having existed since very early versions of the platform. Developers can configure the button’s behavior — how Replit runs their code — by editing a file called .replit: you define a specific run command using the run field, and configure build or compile steps that are pre-requisites to running your project. To make this easier, Replit Templates have these configurations prepared for you in most cases, allowing you to get from an idea to a runnable project, fast.

As Replit’s capabilities have grown from executing code in a read-eval-print-loop into supporting production-ready apps, so has the demand for a flexible, expandable controller in the workspace. The design team took this opportunity to reconsider both the Run Button as a core element of our brand and the experience of coding and running apps in the cloud.

The basic challenge was to design an interface for creating and running a Workflow. We started with a series of sprint-style “jam sessions”, where engineers helped the design team develop a deep understanding of how Apps are configured and how code runs on Replit. Engineers used this time to create wireframes and system diagrams, while design helped identify potential edge cases and opportunities that might influence our approach.

Sometimes this process involves a lot of back and forth, but in this case, it was clear that the right abstraction around the infrastructure was the concept of “Tasks” that combine into “Workflows”. These raw primitives (shell commands, scripts, or workspace actions) can be used to orchestrate more complex Workflows.

Prototype for basic task types
Prototype for basic task types

To provide breathing room for more advanced use cases, we considered various affordances for customizing the run button itself, swapping its behavior and even its “Run” label with custom Workflows defined via a user-friendly UI. We also explored what it could look like to merge the Run Button and the concept of Workflows into our existing CLUI feature, creating a single “runner” for all actions across Replit:

The final challenge was the Workflow builder. We wanted it to feel accessible, while allowing developers to still use the tools they’re comfortable with. We made the system flexible enough that beginners can use the basic selection of available commands, while experts can run custom scripts or shell commands to achieve more complexity.

Workflow editor prototype
Workflow editor prototype

Infrastructure that made this possible

Replit’s infrastructure already has the capabilities to support these features, such as our fast pseudoterminal written in Rust, and our dependency management system. With these services readily available, we can define a configuration schema that efficiently stores how we use these tools (you can find Workflows configs stored in .replit, in easily readable TOML format).

With the added power of our new backend server, pid2, running a complex parallel command turns into a single “run workflow” API call. Pid2 handles all the necessary logic behind running a Workflow, such as spawning each command in parallel, tracking the state of each task, or forwarding user input stream to the executing process, leaving the client with drastically less responsibilities and overhead to manage. Along with the execution of the Workflow, the outputs are also stored within Pid2, thus allowing us to reliably restore the output state between reconnects.

To render the outputs, we use a headless terminal from our multiplayer shell implementation, which effectively supports multiplayer in the console as well. The headless terminal unifies the output state across consumers and allows both the agent and assistant to “see” the outputs of Workflows just as the user would. The workspace’s role is to simply connect to each executed task’s output stream and render the state of the executing processes accordingly.

What’s next

With the vast number of features available in Repilt, expect Workflows to gradually support more task types and use cases. Replit Agent is already using Workflows to define descriptive procedures for running your project, which also serves as an interface for the Agent to view the outputs from running your project and actively debug any issues it encounters.

In the future we think Workflows could be a more generalized abstraction over Replit’s many capabilities, providing a no-code interface for describing complex automations or procedures that both humans and AI can utilize.

There are a lot of exciting possibilities and use cases for Workflows, we’re excited to see what you’re able to build with them on Replit!

More