DEV Community: Timophei Lemeshchenko

Splitting a Swift monorepo shouldn't require git-subtree tricks (so I built a free registry)

Timophei Lemeshchenko — Fri, 14 Aug 2026 13:08:52 +0000

Disclosure: I built Perchly, the tool this post ends up recommending. It started as a fix for my own problem, not a product — and this is the honest version of how it happened.

If your team has more than one Swift package that always version together, you've probably hit this: either you split them into separate git repos and juggle a release per package on every single change, or you keep one repo and lean on git submodules / git-subtree hacks just to make each package independently resolvable by SwiftPM. Neither is great, and I kept seeing people run into it — including a Stack Overflow question from someone trying to split a "newskit"/"the-sun" style theming package into independently versioned pieces without blowing up their repo structure.

The root cause is that swift package-registry publish (and Xcode's dependency resolution) publishes whatever package lives at a given path — so each package you want to version independently needs its own Package.swift, not a shared target inside one giant manifest. That part is actually fine once you know it. The part that's genuinely annoying is that Apple's own answer to "how do I host that privately for my team" is SE-0292, a real open protocol — but there was no simple, free way to actually run one if you're not Artifactory/JFrog-scale.

So I built a private SPM registry that implements SE-0292 for real, not a wrapper around git.

Why not just use a private GitHub repo as a dependency

That works fine for exactly one package. The moment you have several related packages that need independent versions in one repo, you're stuck choosing between:

Splitting into N repos, so every cross-cutting change becomes N pull requests and N releases
Keeping one repo and hacking around it with git-subtree splits or submodules, which nobody enjoys maintaining

A real registry sidesteps this entirely. Each package resolves and versions independently regardless of how your source is actually organized on disk.

What "real SE-0292" gets you

Because Perchly speaks the actual SE-0292 registry protocol instead of a proxy or a plugin, the standard SwiftPM CLI just works, unmodified:

# once per machine/CI runner
swift package-registry set https://registry.perchly.dev

# from inside a package directory
swift package-registry publish my-org.network-kit 1.0.0

Depending on it elsewhere is just:

.package(id: "my-org.network-kit", from: "1.0.0")

No custom tooling, no forked SwiftPM, no post-install scripts. It even works through Xcode's own "Add Package" dependency resolution once you've run the set command once — Xcode doesn't need to know Perchly exists.

For the actual monorepo case, splitting into independently publishable packages just means giving each one its own Package.swift:

my-monorepo/
├── Sources/
│   ├── newskit/
│   │   ├── Package.swift          ← name: "newskit"
│   │   └── Sources/newskit/...
│   └── the-sun/
│       ├── Package.swift          ← name: "the-sun"
│       └── Sources/the-sun/...

They still live in one git repo. Nothing about this requires separate repos, submodules, or subtree splits — you just publish each path with its own identifier and version:

swift package-registry publish --package-path Sources/newskit my-org.newskit 1.0.0
swift package-registry publish --package-path Sources/the-sun my-org.the-sun 1.0.0

I also open-sourced a small CLI, perchly-cli, that diffs the last publish against HEAD, figures out which package directories actually changed, and bumps + publishes only those — so you're not doing that by hand every release once you have more than two or three packages.

Other things it does

GitHub and GitLab OAuth to sign in — no separate account/password to manage
Versions are immutable once published (no silently overwriting 1.0.0 out from under someone who's already pinned to it)
Free plan: 3 members, 5 packages, 2GB storage, no credit card
Paid tiers exist for bigger teams, but the whole point of the free tier is that a small team shouldn't need to talk to sales to stop fighting git-subtree

What it deliberately doesn't do (yet)

No package signing yet (SwiftPM prints an "is not signed" warning but still resolves fine — that's an SwiftPM-level thing, not specific to Perchly). No self-hosted GitLab instance support, no per-package ACLs. It's intentionally a small, focused tool, not an attempt to out-feature Artifactory.

If you want to poke at it: perchly.dev. Feedback, especially "this doesn't work for my setup because X," is genuinely useful to me right now.

Comparing Dart & Flutter package registries

Timophei Lemeshchenko — Mon, 10 Aug 2026 13:18:37 +0000

dart.dev's custom package repositories page lists six providers for hosting private Dart/Flutter packages and doesn't say a word about how they differ. Here's an honest breakdown, including whether you need one of these at all.

At a glance

Provider	Free tier	Cheapest paid plan	Billing model
Cloudsmith	500MB data / 1GB delivery	$149/mo (Pro)	Usage-based (storage + delivery)
Inedo ProGet	Unlimited feeds & users (self-hosted)	$2,395/yr (Basic)	Flat, per-server license
JFrog Artifactory	Free trial only	$150/mo (Pro)	Usage-based (consumption) + tier
OnePub	2 members / 25 packages	$1-$15/member/mo	Per-seat
GLPub.dev	1 package	10 EUR/mo (Pro)	Flat, per-org
Publy	1 member / 5 packages	$19.99/mo (Starter)	Flat, per-org

GLPub.dev prices in EUR, everyone else above in USD. Figures verified directly against each provider's own pricing page as of August 2026 — see the sections below for what each tier actually includes.

Is a registry even worth it over git dependencies?

Dart 3.9 added tag_pattern to git dependencies, which is a genuine fix, not a workaround. Tag your commits with real version numbers and the solver treats a git dep almost like a hosted one — a non-breaking bump no longer cascades through every consumer.

What it doesn't fix: pub identifies a git dependency by its URL, so a teammate pulling over SSH and another pulling the same repo over HTTPS are two different packages to the solver. There's no publish-time validation, so a mismatched tag just sits there until a consumer fails to resolve. Tags are mutable by default, so force-moving one silently changes what a "version" means for everyone who already resolved it. And every dev machine and CI job needs git access to every package repo individually, instead of one scoped, revocable token.

None of that is unsolvable — SSH-only conventions, protected tags, a shared CI service account — but it's all internal policy your team has to set up and keep alive. If you have a handful of git dependencies in their own repos, tag_pattern probably closes the gap enough that a registry is overkill. Past a pile of interdependent packages across monorepos, it stops scaling.

Cloudsmith

Cloud-hosted, general-purpose artifact registry (not Dart-specific — it also handles npm, Maven, Docker, and a long list of other formats). It was the first third-party Dart repository, launched back in 2020. The free Core plan gives 500MB of artifact storage and 1GB of package delivery; Pro is $149/month for 5GB storage and 25GB delivery, plus $1.50/GB beyond that. Ultra and Enterprise are custom-priced. Comes with governance features (blocking versions, requiring metadata, quarantining packages) aimed at larger orgs already managing multiple package ecosystems.

Inedo ProGet

Self-hosted (or their managed Cloud Edition from $4,895/yr), also general-purpose across many package/container formats. Pub support is recent — it landed in ProGet 2024.11 — and inherits a real limitation of the pub API itself: no search, and no README/license metadata without extra caching work. The Free edition supports unlimited feeds and users; paid self-hosted licenses run $2,395/yr (Basic) up to $11,995/yr (Enterprise Essentials) and from $29,995/yr (Enterprise Complete), licensed per server, not per user — every edition supports unlimited users. Self-hosting means you own uptime and patching unless you pay for the managed option.

JFrog Artifactory

The enterprise option. Supports dozens of package formats beyond Dart through local, remote, and virtual repository types, self-hosted or cloud. The Pro tier is $150/month for 25GB of base consumption; Enterprise X starts at $950/month for 125GB plus SSO and artifact federation; Enterprise+ is custom-priced. No free tier for private packages beyond a trial. Makes sense if your org already standardized on Artifactory for other languages and just wants to add a pub feed to it — a lot of surface area to take on if Dart packages are the only thing you need it for.

OnePub

Dart/Flutter-only, hosted, and the longest-running dedicated option in this list. Explicitly billed "USD, per member, per month" on every tier: Free is 2 members / 25 packages, Pro is $1/member (5 members), Team is $10/member (20 members, their most popular), Enterprise is $15/member (unlimited members). A 20-person team on the Team plan is $200/month before storage or download overages — the cost scales with headcount (and typically a CI service account counts as a member too), not with actual usage.

GLPub.dev

Dart/Flutter-only, hosted, and signs in with GitLab, GitHub, or Google — not GitLab-exclusive despite the name, though it reuses whichever provider's project permissions natively. Flat per-org pricing, not per-seat: Free is 1 package with 10 versions/month, Pro is 10 EUR/month for up to 10 packages with unlimited versions, Business is 50 EUR/month for unlimited packages plus priority support. The smallest and newest-feeling option here, but the pricing model is closer to Publy's than to OnePub's.

Publy

Dart/Flutter-only and hosted, priced in flat tiers instead of per seat like OnePub: Free is 1 member / 5 packages / 250MB storage, Starter is $19.99/month flat for 10 members / 50 packages / 5GB (the same 10-member team costs $100/month on OnePub's per-seat Team plan), Team is $39.99/month flat for unlimited members and packages with storage capped at 25GB. Adding a teammate never changes the bill within a tier. Speaks the real pub hosted-repo protocol (the spec dart-lang publishes) directly, not a wrapper around git or a custom CLI, so dart pub publish and dart pub get work exactly like they do against pub.dev.

How to actually pick one

Already running Artifactory or ProGet for other package types at your org? Add a pub feed to what you have instead of standing up something new. Just a couple of small packages and comfortable with GitLab/GitHub-native permissions? GLPub.dev's free or 10 EUR tier probably covers it. Team size small and stable, with only a handful of internal packages? tag_pattern on plain git dependencies might be all you need — skip a registry entirely. Want something Dart-specific and hosted without per-seat pricing creeping up as you hire, or need dozens of interdependent packages across monorepos to just work? That's the gap we built Publy for.

Pricing and feature details above were checked directly against each provider's own pricing page as of the date at the top of this post — registries change their plans, check each provider's own site before deciding.

FAQ

Does pub.dev support private packages?

No — pub.dev only hosts public packages. dart pub itself supports any hosted-repo-protocol-compliant server via publish_to and a custom hosted URL, which is exactly what the providers on this page (or self-hosting the spec yourself) give you.

Is there a free private Dart/Flutter package registry?

Yes. Cloudsmith's Core plan, Inedo ProGet self-hosted, OnePub's Free tier, GLPub.dev's Free tier, and Publy's Free tier all have a $0 option — see the table above for what each actually includes before you rely on it.

What is the pub hosted-repo protocol?

It's the REST API spec dart-lang publishes (the Hosted Pub Repository Specification, currently v2) that dart pub publish and dart pub get talk to — upload finalize with a Location header, a version-listing endpoint, archive downloads. Any server that implements it correctly works as a drop-in publish_to target; that's what distinguishes an actual registry from a wrapper around git or a custom CLI.

Do I need a registry if I only have one or two internal packages?

Probably not. Dart 3.9's tag_pattern lets plain git dependencies resolve against real version tags, which covers small, stable setups fine — see the section above on what it does and doesn't fix.

What happens to already-downloaded packages if I switch providers or stop paying?

Depends on the provider — check before you commit. Publy, for example, keeps downloads unmetered for a full month after a missed payment, and packages your build already fetched keep whatever got cached; only new dart pub get / dart pub publish calls are affected after that grace period.

Can I use more than one of these at once?

Yes — pub supports multiple hosted repositories at the same time, declared per-dependency in pubspec.yaml. Some teams do split package sources this way (self-hosted ProGet for one set of internal tools, a hosted registry for another), at the cost of juggling more than one set of credentials.

Originally published on the Publy blog, where it's kept up to date.

Sharing private Flutter packages shouldn't cost this much (so I built a free registry)

Timophei Lemeshchenko — Tue, 28 Jul 2026 10:39:05 +0000

Disclosure: I built Publy, the tool this post ends up recommending. It started as a fix for my own problem, not a product — and this is the honest version of how it happened.

If you've ever tried to share private Dart or Flutter code across more than one repo, you already know the two roads in front of you, and you already know both of them hurt.

Road one: a paid private pub registry. It works, dart pub is happy, and the bill climbs every time your team or your package count grows.

Road two: git dependencies. It's free, and it quietly turns your pubspec.yaml into a minefield.

I spent a long time on both. Here's what actually went wrong, and what I did about it.

The git-dependency trap

For a while my team went the free route — pull internal packages straight from git:

dependencies:
  app_core:
    git:
      url: git@github.com:our-org/app-core.git
      ref: main

This looks fine on day one. It falls apart on week three.

The moment you reference a package by branch or tag instead of a version, you throw away everything pub's version solver does for you. There are no version constraints — ^1.4.0 means nothing when you're pinned to ref: main. Two apps depending on the same internal package at two different commits? The solver can't reconcile that, because as far as it's concerned they're the same unversioned thing.

So you end up doing this:

dependency_overrides:
  app_core:
    git:
      url: git@github.com:our-org/app-core.git
      ref: a3f9c21   # the "known good" commit, do not touch, nobody remembers why

dependency_overrides is meant to be a temporary, local escape hatch. When it becomes the only way your dependency graph resolves, that's not a workaround anymore — that's your architecture, and it's a bad one. Every new package multiplied the pain. Across two internal SDK monorepos we had 50+ packages depending on each other, and the git approach turned every version bump into a manual archaeology dig through commit hashes.

The whole point of semantic versioning and pub's solver is that you don't do this. Git dependencies opt you out of the one thing that makes Dart's package management good.

The paid-registry trap

So we did the sensible thing and moved to a hosted private registry. And it was genuinely better — real versions, dart pub publish, the solver working again.

Then the invoice showed up.

I won't name numbers, but the pricing scaled per seat, and even with a small team of 3 developers plus CI/CD, hosting our internal packages had become one of those line items you keep meaning to "look into." For a handful of private packages that just needed a place to live, the cost-to-value ratio stopped making sense. I was also paying out of pocket to host packages for my own side projects — and that math was even harder to justify.

I did not want a fancy product. I wanted the boring thing: a place to dart pub publish internal packages, with real versions, that didn't charge me per human.

So I built Publy

I'm a Flutter dev, not a SaaS founder, and I built this because the alternatives annoyed me — so it's deliberately small. Publy is a private Dart & Flutter package registry that implements the standard pub hosted repository spec. That last part matters: there's no custom CLI, no plugin, no wrapper. dart pub publish and dart pub get work exactly like they do against pub.dev, because to dart it is just a hosted registry.

Setup is three commands and one pubspec block.

1. Authenticate the CLI (after signing in with GitHub and creating an org + token):

dart pub token add https://publy.dev/o/your-org

2. Tell a package where to publish — in that package's pubspec.yaml:

publish_to: https://publy.dev/o/your-org

dart pub publish

3. Consume it from another repo like any hosted dependency — real version constraints, back at last:

dependencies:
  app_core:
    hosted: https://publy.dev/o/your-org
    version: ^1.4.0

That ^1.4.0 is the whole reason this exists. The solver is doing its job again. No ref, no commit hash, no dependency_overrides graveyard.

What it is and isn't

Being honest about scope, since I hate posts that oversell:

It's free. Not free-trial, not free-tier-with-an-asterisk — the plan you'd use for a small team costs nothing. I built it so I'd stop paying for this, so charging small teams would defeat the point.
Auth is GitHub OAuth for the web UI and bearer tokens for the CLI / CI.
Versions are immutable — republishing the same name@version is a 409, never a silent overwrite.
It's young. No per-package ACLs, no download analytics, no billing gymnastics. If you need enterprise compliance features today, this isn't that yet.

If you're a small-to-medium Flutter team quietly bleeding money on a private registry, or worse, drowning in git-dependency overrides — this is aimed squarely at you.

Try it

You can be publishing in about five minutes: publy.dev, and the getting-started guide is the same three commands above with pictures.

If you try it and something's broken or missing, tell me — genuinely. It exists because I hit a wall, and the fastest way to make it good is other people hitting different walls.

What's your current setup for private Flutter packages — paid registry, git deps, or something cleverer? Curious what everyone else landed on.