I did not need a second software company in my toolbox. I needed a safe copy of the code.

This morning I moved 13 git repositories off GitLab and onto Cursor Origin. Full cutover. New remotes. Old GitLab projects deleted. One repo stayed: Coded Content. That one still uses git to move from development to production. The rest of our sites do not. They go live over SSH. For those, git was backup. Origin is built for that job — and it lives inside the editor I already use all day: Cursor.

Same family of decisions as I'm Done With WordPress and why I built our own member portal instead of renting Skool. Softer this time. GitLab was not broken. It was just more than I was actually using.

GitLab was not the problem

GitLab is a serious platform. Issues. CI. Merge requests. Pages. The whole operating system around code.

I was not using that operating system. I was pushing so the work existed somewhere besides my laptop. If the MacBook dies, the history should not die with it. That is a backup problem. Treating it like a full DevOps suite is how you collect tools you do not operate.

Nothing about GitLab annoyed me. No vendetta. No “the UI got worse.” It simply felt unnecessary for how these 13 projects actually ship.

What “git as backup” means in our stack

Most of our sites live like this: edit locally in Cursor, commit, then move files to production over SSH. Knup.com is in that group. So are bigger brands in the ecosystem — Sports Mentorship, Ideal Homeschool, Rewritten, and a handful of smaller repos that add up to 13.

The remote was never the deploy button. The remote was insurance. History. A copy I could clone on another machine. If that is all you need, a simpler private host that sits next to the editor is cleaner than a second dashboard you open twice a month.

Coded Content is the exception on purpose. That product still promotes with git. Until Origin is further out of beta, I am not moving the one repo where the remote is part of the production path.

Why Cursor Origin fit this morning

We are already all in on Cursor. Sites, member tools, content systems, the vibe-coding workflow. Origin is git hosting inside that same world: origin.cursor.com, same login, CLI that matches how we already work.

  • Simple. Create a repo. Point the remote. Push. Done.
  • Integrated. I am in Cursor anyway. One less account to remember.
  • Private. These repos are not public open-source. They are backups of businesses. Origin is not trying to be a public GitHub page. That is a feature for this use case, not a limitation.
  • Honest about beta. I am not pretending it is finished infrastructure for every workflow. That is why Coded Content stays on GitLab for now. We will see where Origin heads after beta.

Thirteen projects in a morning only happens when the new home is smaller than the old one. If I had been rewriting pipelines, I would still be on project three.

Already Building in Cursor?

Cursor is the editor. Origin is the backup remote.

If you are already shipping in Cursor and you mostly need a private place for git history, Origin is the piece that made GitLab feel like extra furniture.

Try Cursor

The cutover was boring. That is the compliment.

Full cutover. Not “also push to Origin and keep GitLab around just in case.” New remotes. Confirm the push. Delete the GitLab projects. If you are going to simplify, simplify.

I am not going to write a tutorial. Your remotes, SSH keys, and repo names are yours. The decision is the post. The mechanical work was a morning because the requirement was small: private history, same Cursor login, no extra ceremony.

Why Coded Content stayed

Coded Content is the AI sports content system — licensed data, automation, publishing. That repo still uses git as the path from development to production. The others do not. They move with SSH file deploys.

Different job, different host. I am not dragging a production promotion flow onto a product that is still in beta just to make a blog post cleaner. GitLab keeps that one job until Origin proves it wants that job too.

That is not loyalty theater. That is matching the tool to the actual motion. Same idea as one brand versus a pile of niche sites: extra platforms feel productive until you notice they are not doing work.

Who should stay on GitLab (or GitHub)

Stay if git is how you ship. Stay if you run CI, review, issues, or a team that lives in merge requests. Stay if you need public repos. Origin is not that product today, and I am not going to sell it as that.

Move a backup-only stack when:

  • production is SSH, rsync, or a host panel — not git pull on the server,
  • you are already in Cursor every day,
  • you want private history without a second company dashboard,
  • and you can leave the one “real pipeline” repo where it already works.

This is stack hygiene, not a religion

I keep cutting rented rooms we are not living in. WordPress as the default. Skool as the school. GitLab as the museum of code I already have locally. Each one earned its season. Each one can still be the right answer for someone else.

For me, fewer tabs. Same editor. Private backups. One exception that still earns GitLab. That is enough.

Need Help Simplifying?

Built by Knup is for the messy middle

If your stack is a pile of “we might need this later” tools and you want a cleaner build, deploy, and backup story, that is the work.

View Built by Knup

Final thoughts

I only needed git as a backup. Cursor Origin is private git next to the editor I already pay attention to. Thirteen repos moved this morning. GitLab projects gone. Coded Content stays until Origin is ready for a real promote-to-production flow — or until it is not, and we keep GitLab for that one job.

Use the serious platform when you use the serious features. Use the simple remote when you need a copy of the work. Delete the extra museum.

Two Paths

Build in Cursor, or get help cleaning the stack

Already coding in Cursor and want git in the same place? Start there. Need a simpler site, backup, and production story for the business? Talk with Built by Knup.