Forking a Repository

This is the killer feature: clone an entire production environment (the app, the database, the config files) in seconds. Any size. Zero extra disk. Fork as many times as you want.

The tagline: clone production, break nothing.

Watch the tutorial

Set up something to lose

First, give the running app a file so you can prove the fork’s isolation. Open the repo in VS Code:

rdc vscode connect -m my-server -r my-app

Inside the repo, create a marker file:

time echo "Hello from production" > index.html

Now fork it.

Fork

time rdc repo fork --parent my-app -m my-server --tag experiment --up

One command. It cloned everything (the app, the database, the config files) and it happened in seconds. Run it again and you get another independent clone.

Why is it so fast?

Imagine sharing a folder link. The link is the same whether the folder is small or huge. The folder is heavy, the link is light.

Forking works the same way. 1 GB, 100 GB, 1 TB. Same time, every time.

What’s shared, what’s yours

Think of the parent repo as the sun. You can’t hold the sun, but you can hold a mirror that catches it. That mirror is your fork. Paint on the mirror, and your drawings are yours. The sun stays the same, no matter how many mirrors face it.

You can’t hold the sun, but you can hold it in a mirror.

What if the parent changes later?

Now think of a river. The water keeps flowing. Every moment, it’s different. When you fork, you take a photograph of the river, frozen at that moment. The river keeps flowing. Your photograph doesn’t.

If the parent repo changes later, your fork stays where it was.

You can’t hold a river, but you can hold it in a photo.

Disk usage stays flat

That’s why your disk doesn’t blow up. Five forks of a 100 GB repo? Still about 100 GB total. You only pay disk for what you change in each fork.

Fork five times if you want. Your disk won’t even notice.

What forks do not inherit: secrets

There’s one thing the fork deliberately doesn’t follow: secrets. A fork starts with no API keys, no database passwords, no Stripe tokens. That’s why “clone production, break nothing” actually works. Your sandbox can’t bill real customers because it can’t pretend to be you. We set this up properly in the Managing Secrets tutorial.

Verify the isolation

List both repos side by side:

time rdc repo list -m my-server

You’ll see my-app and my-app:experiment running concurrently.

In the original repo, check what’s running:

time docker ps

Note the uptime. These are the original containers. Now switch to the fork:

rdc vscode connect -m my-server -r my-app:experiment

time docker ps

Same images, but the uptime is fresh. These started when the fork did.

Make the difference even more obvious. Add a container only to the fork:

time docker run --rm -it -d nginx
time docker ps

Nginx is running, but only inside this fork.

Try something destructive:

time rm index.html

Gone here. Now jump back to the original:

rdc vscode connect -m my-server -r my-app
time docker ps

No nginx. The fork’s containers stayed in the fork. And index.html is still here, untouched. The original never knew anything happened. Same images, separate Docker daemons, separate filesystems.

Clean up

When you’re done, just delete the fork:

time rdc repo delete --name my-app:experiment -m my-server

The original stays exactly as it was. Fork, experiment, break things, delete. No risk.

---

Next: Managing Secrets.