Skip to main content
A project is the container for everything you build on Replit. A project contains your designs, apps, slides, data, and all the outputs you create. Artifacts are the publishable outputs inside a project: web apps, mobile apps, slide decks, and videos. When you’re building more than one thing, you have two options:
  • add multiple artifacts to a single project,
  • or create separate projects.
The right choice depends on whether your apps share data, logic, and a deployment lifecycle. This guide covers when to keep artifacts in a single project and when to create separate ones.

​
What artifacts share in a project

When artifacts live in the same project, they automatically share:
  • Database: One artifact writes data, the others read it instantly
  • Backend and API: Shared server logic, no duplicate code
  • File storage: Images, documents, and uploads accessible across artifacts
  • Deployment: Publishing deploys everything together in sync
This means you don’t need to set up connections or duplicate code between artifacts. But it also means you can’t publish one artifact without publishing the others.

​
Quick guide

Here are the key scenarios to consider when deciding whether to add artifacts to an existing project or create a separate one.
Use multiple artifacts in one projectUse separate projects
Apps share the same data and backendApps don’t share underlying logic or data
You want everything to deploy togetherYou need independent deployment cycles
They’re complementary (like a customer app and an admin dashboard)They’re unrelated products or for different clients
You want changes in one artifact to automatically reflect in the othersThe project is short-lived, like a campaign landing page or event site

​
Examples

​
Same project: Web app + mobile app for one product

A restaurant builds a web app for customers to browse the menu and a mobile app for staff to manage orders. Both connect to the same database of menu items, orders, and customer information. Why one project: The apps share the same data and backend. When a customer places an order through the web app, the staff sees it immediately on the mobile app.

​
Same project: App + admin dashboard + investor pitch deck

A startup builds their main product, an internal admin panel for managing content, and a slide deck for fundraising—all in one project. A startup builds their main product, an internal admin panel for managing content, and a slide deck for fundraising — all in one project. Why one project: The admin dashboard manages the same data the app displays, and the pitch deck can reference live metrics from the shared backend.

​
Separate projects: Two unrelated client apps

A freelancer builds an e-commerce store for one client and a booking system for another. Why separate projects: The apps have no shared data or logic. Each client needs independent deployment and you don’t want changes to one affecting the other.

​
Separate projects: Campaign landing page alongside a main product

You have a production app that runs year-round and a short-lived landing page for a marketing campaign. Why separate projects: The campaign page has its own lifecycle — you’ll spin it up, run it for a few weeks, and take it down. Keeping it separate avoids cluttering your main product and lets you publish or remove it independently.

​
Frequently asked questions

Not currently. If you need to separate an artifact, create a new project and ask Agent to rebuild it there.
There’s no hard limit. Add as many artifacts as your project needs. Your web apps, mobile apps, slides, videos, and data visualizations can all coexist.
Not currently. Publishing deploys everything together. If you need independent deployment, use separate projects.