What does cloning a Rork project actually do?

Cloning creates a full copy of your current project state, the code, the data model, the configurations, ready for you to iterate on independently of the original. The two diverge from the moment of the clone. Changes in one do not affect the other.

When should I clone, exactly?

Six common moments: (1) your project gets stuck in a loop of bad generations and you want a clean restart from a known-good state, (2) you want to experiment with a major change without breaking the live version, (3) you want to fork the codebase for a different use case (an internal version and a client-facing version), (4) you want to give a copy to a teammate to iterate on while you continue, (5) you want to roll back from a recent state without losing the in-between progress, (6) support asks you to clone for troubleshooting.

Does cloning duplicate my Supabase database too?

No. Cloning is the Rork project (code + configuration). Your Supabase database is a separate thing. If you want a fresh database for the clone, create a new Supabase project and point the cloned Rork project at it. If you want the clone to share the live database, you can do that too, both projects connect to the same Supabase.

What happens to my App Store listing if I clone?

Nothing changes for the original. The clone is a new project, so to ship it as an app you would either submit a new listing or update an existing one. Most operators keep one App Store listing for their main app and use clones for internal experimentation.

Can I merge changes from a clone back into the original?

Not automatically. Clones are forks, the right model is 'pick a winner and keep iterating on it.' If you've been experimenting on a clone and want to bring something back, the easiest way is to describe the change to Rork in the original project and have it rebuild that specific feature. The codebase is small enough that this is fast.

How often should I clone as a safety habit?

Before any major refactor or schema change, clone. It's the difference between 'I'll just try this' and 'I have a backup if this goes wrong.' Cost: zero. Time: a few seconds. Confidence gained: enormous.

When to Clone Your Rork Project (and When Not To)

Cloning a Rork project sounds like a tool of last resort. It is actually one of the most useful operator habits, used at specific moments to keep your build clean.

Most operators learn this the hard way. They get into a tangled state, ask support how to fix it, and support says "clone the project." They wonder why they did not just do that earlier.

This guide is to skip that lesson.

The Six Moments to Clone

1. You Are Stuck in a Loop of Bad Generations

You ask Rork to add a feature. It builds it wrong. You ask it to fix. It breaks something else. You ask it to fix the second thing. The first thing breaks again. You are in a loop.

At this point: clone from the last known-good state (yesterday's project, or wherever your last clean build was), and re-attempt the feature with a different prompt. Sometimes a fresh start with a cleaner approach is faster than the eighth attempt.

2. You Want to Try a Risky Change

You are about to refactor your data model. Or you want to try a completely different navigation structure. Or you want to test what happens if you replace Supabase with a different backend.

Clone first. Try the risky change on the clone. If it works, you have your new baseline. If it does not, your original is intact.

3. You Are Forking for a Different Use Case

Your construction company app works great for your business. Your friend's restaurant company asks if you can build them something. The data model is mostly the same (clients, jobs, payments), the workflow is different.

Clone the project, change what is different, ship to your friend's business. Now you have two Rork projects, one per business, sharing nothing but the foundation.

4. You Want to Hand It to a Teammate

You are running plan mode on a complex feature. You want a teammate to start experimenting with a parallel idea. You clone, hand them the clone, you continue on the original. You both make progress without stepping on each other.

5. You Want to Roll Back Without Losing Recent Work

You made changes last week that you now regret. But you also made changes today that you want to keep. Cloning from the today version, then selectively un-doing the regretted week-ago changes, is often easier than restoring from a backup.

6. Support Asks You to Clone

When you raise a support ticket and the team needs to reproduce the issue, cloning lets them get an exact copy of your project at that moment. This is standard practice and is often the first request.

When NOT to Clone

Cloning is cheap but not free. The cost is proliferation. Three months later you have eleven copies of the same project, none of which is clearly "the live one." Avoid this.

Cases where cloning is the wrong move:

You want to make a small change. Just make the change. If it breaks, undo it.
You want to back up your project. Cloning is not backup. Use proper backups (Supabase export, code export, etc.).
You want to share your project with someone. Add them as a collaborator instead, if Rork supports it for your tier. Do not clone-and-share.
You are not sure why you want to clone. Wait. If you do not have a clear reason, you do not need a clone yet.

The Clean-Project Habit

Operators who avoid the eleven-clone-mess use a simple pattern:

One "live" project. This is what your team uses. Treat it like production.
One "experiment" project. Cloned from live whenever you want to try something risky. Renamed clearly: "Construction app - Q4 refactor experiment." Disposed of when the experiment is done.
Annual checkpoint clones. A clone at the end of each year or major release, as a frozen snapshot. Renamed clearly: "Construction app - 2026-12-31 release." Never touched again.

Three to five projects total at any time, all clearly labeled. Not eleven anonymous copies.

What Operators Wish They Had Known

Three things:

Clone before major refactors. Cost: seconds. Confidence: 10x. Just do it.
Rename clones immediately. "Project copy" is the death of organization. Rename to "Original - experiment X" or "Original - 2026-Q3 checkpoint" right when you create the clone.
Delete dead clones. Quarterly, look at your project list. Anything you have not opened in 90 days that is not a labeled checkpoint, archive or delete. Free your future self from project-list noise.

When This Becomes a Workflow

After a few months of building seriously in Rork, the clone habit becomes second nature. You will clone before a Friday afternoon experiment, run it, then either promote it to live or throw it away. The "fork & test" loop is how teams of developers work in real codebases. As an operator with Rork, you get it for free.

For related operator habits:

What to Do This Week

If you have a Rork project right now and you have been afraid to try something risky: clone it. Try the risky thing on the clone. Decide which version wins. Move on. The fear goes away the first time.