Blog

Moving my personal projects to OneDev

10/26/2026

  • Development

I’ve recently moved all of my personal, and a chunk of the professional projects for Prestanda over to OneDev. Most of the reason for that won’t actually be solved by this move, ironically, as my frustration with Github is mostly a problem in the day job. I’m not in control of where we do our code storage there, but taking some control of my personal projects has helped scratch the itch anyway.

This isn’t just about storing code, though, and if it was I probably wouldn’t have bothered. Read on to get the full lowdown.

Where my projects lived before

I think it’s fair to say that the vast majority of devs default to Github for storing code and running things like CI/CD workflows. Same here. Most of my projects are private, whether that’s because they are somehow work related or because they aren’t meant for use by a wider community.

Various things had been getting me itchy about trying out another platform recently, including:

  • Github’s meme-worthy downtime levels
  • Shortcomings of issue management on Github (I love a Kanban board, me). I’d recently self-hosted Kaneo and enjoyed it.
  • Experimentation with Agentic orchestration with things like Paperclip
  • A VPS that was sitting doing not a lot

Why OneDev

I can’t remember exactly where I saw OneDev first, but it will likely have been on a YouTube video somewhere, and it seemed to tick a lot of my boxes:

  • Self-hostable
  • Clean issue management
  • Agent-native without being Agent-first
  • Not Github

Having one URL I can go to to deal with everything to do with my projects is a massive plus for me. Setting up an issue for a bug or feature and then going through my workflows for implementation all in one place is very powerful.

I can lock it down nice and tight, while still inviting specific individuals to specific projects to impact in their own way. The same is true of agents, which I can set up with their own sandboxed environments that get built and torn-down automatically on an issue-by-issue basis.

Setting it up

Set-up was pretty simple, I amended the instructions on the quickstart guide to my VPS setup and started setting up the first project. Ironically that was this site, because this was a fresh build that made sense to use without all the baggage of dragging across from Github and project management stuff.

Moving the projects across

Once I had a bit of a handle on how projects should be setup, I moved one more personal project over manually – that included getting all the outstanding issues in with their labels and state, a ‘workspace’ setup for an AI agent, migrating over the workflows etc.

A couple of little gotchas in that manual process helped me then build out a good spec of how to do things for Claude, and that just moved the rest over for me.

CI with build specs

Each project includes a .onedev-buildspec.yml file which fairly neatly mimics the workflow YAML files you may be used to on Github. OneDev is pretty good at suggesting a good baseline template based on the code of a project, but the whole thing is also very extendible.

One great piece of the whole puzzle of migrating to this is that I don’t have to worry about Actions budgets now. Once I tuned the concurrency of builds and other jobs to the specs of my VPS I can go nuts with what my CI/CD workflows look like to make sure that the various automations I want are done, rather than the ones that fit some budget.

This site is one example: OneDev builds it, checks the performance budgets (which I wouldn’t probably bother with on a personal site otherwise), and deploys it to Cloudflare Workers.

What I miss

Honestly, not a lot. Everything you’d expect is there from good issue management and assignment, through pull request workflows (including auto merge and branch protections etc) and the like.

The only small gripe I’ve had so far is not being able to obviously see the state of CI/CD on a PR without opening a little sidebar. I can live with that.

Would I do it again

Absolutely. For someone doing what I’d call a ‘small to medium’ number of projects, who likes a bit of agent use but also still actually enjoys being a developer and so wants it as a tool and assistant rather than whole dev team, this is pretty close to perfect.