We locked the wine registry down. Now you can have it.

A few days ago we made the shared wine registry harder to copy: anonymous readers now get prose instead of structured data, bulk paging is gone, every reader is counted, and a few wines exist only to catch copiers. Today we are handing the registry to anyone who runs their own Cellarion.

That is not a contradiction. It is the order things had to happen in. You cannot share a thing generously until you can tell sharing from taking. Once the counters, the canaries and the terms were in place, the question "how do we give self-hosters the registry?" finally had an answer that was not "give everyone the registry".

If you run Cellarion on your own server, you have always had the app and never the data. Every wine you add starts from a blank record: name, producer, appellation, typed by hand, no tasting profile, no drink window. On cellarion.app those come from the shared registry, a curated database that a sommelier routine and a lot of label-reading owners keep tidy. The Registry Bridge gives your install a share of that, one wine at a time.

The idea in one picture

Think of the registry as a bonded warehouse. The goods stay inside. Your install gets a permit, draws out the single wines you actually add to your cellar, and keeps only those. It can send goods back in: a wine request, a correction, a value read from a label. It can never load the warehouse onto a truck.

What it feels like

You add a bottle on your own Cellarion and type the name. Your local wines come up first, as before. Below them, marked as coming from the registry, come up to ten matches from cellarion.app: producer, name, appellation, region, a label image. Nothing has been downloaded yet.

You pick one. That single wine is fetched in full and copied into your database: identity, tasting profile, drink windows per vintage, and the public values people have contributed, such as ABV. From then on it is your wine; the profile and the window render exactly as they do on the hosted site. Once a week your install asks the registry whether any of the wines it holds have changed, and refreshes those. Anything you changed yourself on a copy stays as you set it: a drink window, a value, the name on the label. And if you would rather have no refresh at all, one line in your .env turns it off.

If a label tells you the record is wrong, or you know an ABV the registry does not, you file it from your own install and it lands in the same queues the hosted site uses, credited to your account and your install.

Getting a key

1. Update your install to the current release, and take the new compose file with it: the two variables below have to reach the backend container, and an older compose file does not pass them through.
2. Sign in on cellarion.app, open Settings, and find "Connect a self-hosted Cellarion".
3. Read and accept the Registry Data Terms, name your install, confirm your password.
4. Copy the two lines into your install's .env and restart the backend.

REGISTRY_BRIDGE_URL=https://cellarion.app
REGISTRY_BRIDGE_KEY=cbr_…

That is the whole setup. Two keys per account, shown once, revocable with one click. It is free; what it costs you is an account and a promise.

The promise

The Registry Data Terms are short and written in plain language: use the registry for your own cellar, contribute if you can, do not copy it in bulk or redistribute it. The registry as a collection is protected by the EU database right, and the terms say so. That is the second lock. The first lock is technical.

What crosses the bridge, and what never does

Crosses: up to ten identities per search; one full wine at a time; change answers for wines you already hold; your requests, corrections and values going back in; your own quota use.

Never crosses: any bulk listing or paging of the registry; a snapshot or export, encrypted or otherwise; a feed of all changes; the similarity data behind "wines like this"; the sommelier's working notes; the internal identities of curators.

We considered shipping an encrypted snapshot to self-hosters and rejected it. Once a dataset is on someone's disk it gets copied, and keys get extracted. So the data stays where it is, and the code that reaches it is open: the client lives inside the self-hosted backend you already run, and the protocol is documented in the repository, because any key holder can read it on the wire anyway. Open code, closed access.

Limits, and why they are generous

Quotas are per key and per day. At the moment they are 600 searches, 300 wine fetches, one change check and 50 contributions, with a burst limit of 60 requests a minute. A household never notices them. If you are importing a whole cellar, open the import window from Settings: every quota is multiplied by five for 24 hours, once a month. Adding bottles must stay painless; that was the rule the whole design was tested against.

The limits are not there to make the bridge hard to use. They are there to make walking the registry through a key slow and visible.

How we notice abuse

Every wine fetched through a key is counted against the account that owns it, for that day, alongside every other reader of the registry. A household reads tens of wines a day; a copier reads thousands, and that difference is what the daily report looks at. There are also canary wines in the registry: records that exist only to detect copying, reachable by id but never through search or add-bottle. A key that fetches one is named in the admins' inbox at once. A key that walks the registry is revoked, and its owner sees the reason in their own Settings. The counting is per account, not per key, so minting extra keys raises nothing and hides nothing.

What happens when a key misbehaves is written down in the repository, step by step, so nobody has to guess: look, ask, tighten, revoke with a reason. None of this makes copying impossible. It makes it slow, visible and against the terms you accepted, which is the honest limit of what a small open-source project can promise.

Privacy

A bridge key and its counters are your personal data: they are in your account export, deleted with your account, and the daily usage rows expire after ninety days. Your users' bottles never travel over the bridge. What does travel: the wine searches typed on your install, and the corrections, values and wine requests your users file, which are forwarded to the shared queues while the bridge is on.

Self-hosters wanted: the beta

The bridge is new, and the only installs that have used it so far are ours. Before we call it done we would like a handful of self-hosters to run it for real: create a key, add a few bottles through it, let the weekly refresh run, and tell us what happened.

What we most want to hear about:

• Search results that were wrong, missing or in a strange order.
• A copied wine whose country, region, appellation or grapes did not land in your own taxonomy the way you expected.
• Profiles or drink windows that look different on your install than on cellarion.app.
• Anything in Settings, the .env step or an error message that made you stop and think.
• How the quotas felt during an import.

To join, reply in the "Registry Bridge beta" thread on the GitHub discussions board, or open a support ticket on cellarion.app from the account that holds your key. Tell us roughly how big your cellar is and what you run the install on. There is nothing to sign up for beyond that, and nothing extra for testers except that your feedback shapes what ships next, and a thank-you here if you want one.

Thanks

The bridge exists because self-hosters asked, politely and repeatedly, for the one thing the hosted site had that they did not. It also exists because the people who read labels for the registry keep making it worth sharing. The protocol, the client and the enforcement playbook are documented in the repository, and the discussions board and the issue tracker are open.