Skip to main content
Replit runs your code in a sandbox, an isolated development environment in the cloud. Your repository, development tools, and running app live there while you work through chat. Your production app stays hosted where it is. The sandbox runs in a microVM, a lightweight virtual machine that isolates the development workload. A reusable environment can provide its setup. Learn more about environments and sandboxes.

From your repository to a reviewed change

Connect GitHub and run a repository with Replit, request changes and check the preview, then propose a draft pull request for your team to review and merge.

1. Repository access and a running preview

When you connect your GitHub or GitLab account, Replit can access repositories through the permissions you authorize. The connection does not grant permissions you don’t already have. When you provide a repository URL and ask Replit to run it, Replit clones the code into a sandbox. The instructions and skills stored with your code come with it:
  • AGENTS.md and CLAUDE.md: Guidance such as coding conventions, setup commands, and required checks. Instructions apply within their directory scope.
  • Skills: Task-specific instructions in SKILL.md files. Replit discovers enabled skills under .agents/skills and .claude/skills, including nested directories, and reads relevant skills when needed.
Replit prepares or reuses the development setup, installs the dependencies, and starts the app. It reads relevant code and guidance rather than loading the entire repository into the conversation. The editor brings the running preview and your chat together. You can interact with the app while discussing the code or a potential change with Replit. The Replit editor shows chat on the left, the running app preview in the center, and Details on the right. A preview is your development version, not a production deployment. The working setup can be saved as a reusable environment for future chats. The editor controls are explained in Navigate your editor.

2. Changes in the development copy

When you describe a change, Replit edits the development copy using the existing code and repository guidance. These edits do not immediately update the shared repository. The preview lets you inspect the result and give feedback in chat. Replit can also test the app in a browser and run repository checks. Its results help you understand what was verified and what remains uncertain before the contribution is proposed. This process supports small corrections and larger features.

3. Working with a team of agents

One main chat can coordinate multiple independent tasks. Replit hands each task to a worker agent in a separate chat and brings the findings or results back to the main chat. The main chat branches into two worker agents, each handling a task in a separate chat. You can follow each task individually while keeping the overall conversation in your main chat. See Agents for the concepts, or Work with a team of agents for an example.

4. A draft pull request

When you ask Replit to open a draft pull request, it creates a contribution branch, commits and pushes the changes, and opens the request on your behalf. In GitLab, this is a draft merge request. The request explains what changed and can include test results and visual evidence. Your team can inspect the proposed changes without bringing them into the target branch yet. A draft signals that the contribution is not ready for final approval. Marking it ready for review moves it into your team’s review process. Git essentials explains branches, commits, and pull requests.

5. Review, revisions, and merging

Your team reviews the contribution and leaves questions or suggestions. Replit can help address the feedback, check the revisions, push them to the same branch, and reply to comments. The existing request updates as the conversation continues. Once the required reviews and checks are complete, you or an authorized teammate can merge the contribution. Your repository’s permissions and branch rules still apply. Merging incorporates the change into the target branch. Deployment follows your team’s release process; some teams deploy automatically after merging, while others release separately.
Isolation does not remove permissions granted to code running in the sandbox. Development credentials should have only the access needed. Personal repository access and shared access for background environment builds are separate; see Manage repository access and Security.