Network exposure
Two questions decide an instance's network posture: what can reach in, and what can reach out. On a self-hosted box you control both, and the defaults lean closed.
What can reach in
By default the instance is only on your LAN. It listens on the box's address and port, and anything on the same network can open it; nothing outside can. Turning on HTTPS changes the reachability depending on which option you pick, and the tradeoff is the whole point of the choice:
- LAN only, or Tailscale. Nothing is forwarded to the internet. Tailscale puts your devices on a private mesh with real certificates, so the same URL works at home or away with nothing exposed. This is the recommended path.
- DuckDNS or Cloudflare. These point a public name at your box so you can
reach it from anywhere, which means forwarding a port on your router. The
instance is now on the internet, so close signup (
PUBLIC_SIGNUP_ENABLED=false) and rely on login.
The setup and the full comparison are in Install.
What can reach out
Cobblr makes no unsolicited outbound call. A handful of features contact a
third-party service, but only when you use that feature, and each has an off
switch in .env:
| Feature | Reaches | Switch |
|---|---|---|
| Built-in AI | the LLM provider whose key you supplied | COBBLR_AI_ENABLED=false |
| Barcode lookups | product catalogs on a scan | COBBLR_SCAN_EXTERNAL_LOOKUPS=false |
| Bundle catalog | nothing. Your instance builds and serves its own catalog from the bundles it ships | nothing to switch off |
| Installing a sandboxed module | the module registry index, on GitHub by default | COBBLR_REGISTRY_URL, or don't install sandboxed modules |
Item image search (fetching a catalog photo) contacts an image search only when you use the image picker or photo enrichment; it has no dedicated flag yet. The per-provider barcode knobs and a full air-gap recipe are in Privacy, and the account-level story of what's yours is in Your data.
For a deployment with no outbound calls at all, set COBBLR_AI_ENABLED=false and
COBBLR_SCAN_EXTERNAL_LOOKUPS=false, use the offline TLS option, skip the image
picker, and install no sandboxed modules. Browsing and installing bundles keeps
working, since that catalog never leaves the box. With no route out, the
remaining calls just fail rather than leaking.
The guard on outbound connections
Some features connect to addresses you supply: a printer or sync source on your network, a device driver, a webhook. Every one of those outbound fetches goes through one SSRF guard, so a supplied URL can't be turned into a request the instance shouldn't make.
The guard always blocks link-local and cloud-metadata addresses (the
169.254.0.0/16 range that exposes cloud instance credentials, and IPv6
link-local), on every hop of a redirect, resolving the hostname first so a public
name that maps to a blocked address is caught too.
On a self-hosted instance it allows your own LAN by design. That's your network,
and reaching a printer or a sync source at 192.168.x.x is the point. The one
exception is those metadata and link-local ranges, which stay blocked no matter
what you supply.