DEV Community: Jessé Cruz

how i run a private package registry on infrastructure i control

Jessé Cruz — Sun, 20 Sep 2026 18:12:08 +0000

i want private packages to live on infrastructure i can operate.

i want to know where the service runs, where the artifacts are stored, and how it is backed up.

omni line is self-hosted, so i can run it with docker compose, ansible, or helm.

for a first deployment, i use docker compose.

the installer sets up the compose assets, writes the environment configuration, and starts postgres, the server, and the client.

for a remote host, i set the public URL during installation.

for production, i put tls at the edge and set the public server and frontend URLs to the HTTPS origin.

i start with the default local storage when i am evaluating the service.

when i need object storage, omni line supports an s3 compatible storage configuration.

when i need a separate database service, the compose deployment can use an external postgres instance.

those choices do not change the package manager workflow.

they change how i operate the registry.

i also plan backups as part of the deployment.

that means backing up postgres and the artifact storage.

if artifacts are stored in an s3 compatible bucket, i back up the bucket.

if they are stored on a local volume, i include that volume in the recovery plan.

i do not expose postgres on the host just because it is part of the stack.

i keep the registry behind TLS.

i keep the installation URL consistent with the URL developers use.

this matters because the browser, management API, and package clients all depend on the same public origin.

self-hosting does not remove operational work.

it gives me a clear place to do it.

i operate one package service instead of a different product for every ecosystem.

then developers, ci, and agents keep using the package tools they already know.

how i give agents a safe path to publish internal packages

Jessé Cruz — Sun, 20 Sep 2026 18:10:32 +0000

i do not think an agent should receive broad publishing access by default.

publishing changes the package supply chain.

it deserves an explicit path.

that does not mean agents cannot help with releases.

it means the permissions should match the work.

with omni line, i use personal access tokens for package manager traffic.

i can give an agent registry:read when it needs to install internal dependencies, inspect a package, or prepare a change.

i only use registry:write for a workflow that is intended to publish.

i keep that publishing token separate from ordinary read access.

the token itself is not the only safeguard.

omni line intersects its scopes with the user’s role in the organization.

that keeps an agent from gaining more registry permission than the underlying role permits.

i also make the task explicit.

i can ask an agent to update a version, run tests, build the package, and prepare a release.

i can ask it to publish only when publishing is the requested action.

i do not make publish an implied final step.

this matters when the project has automation across developer machines, ci runners, and agents.

they can all use the same npm registry URL.

they can all use familiar npm commands.

their tokens can still represent different responsibilities.

i can revoke a dedicated workflow token when the automation changes.

i can create a new one with a narrower scope when the task changes.

i can keep the complete token out of the repository because it is only shown once at creation.

that is the publishing model i want for agents.

the agent can do real release work.

the team can still decide what it is allowed to publish and when.

automation gets a path forward.

human ownership of package access remains clear.

how i give coding agents access to private packages without sharing credentials everywhere

Jessé Cruz — Mon, 07 Sep 2026 12:06:29 +0000

i want agents to use the same private packages as the rest of the team.

i do not want to share my personal token with them.

i also do not want to keep npm tokens inside every repository.

with omni line, i create a separate personal access token for each workflow.

an agent that only installs packages gets registry:read.

a release workflow that publishes packages gets registry:read and registry:write.

the token does not bypass the user’s role.

a reader cannot publish just because the token includes registry:write.

this keeps access simple.

developers, ci, and agents use the same npm registry URL.

they use the same npm commands.

what changes is the token and the permission behind it.

i store each token in the project or deployment secret manager.

i do not commit it to the repository.

when a workflow no longer needs access, i revoke its token.

the agent gets access to the packages it needs.

the team keeps control over who can install, publish, and manage the registry.

How to set up a private npm registry. The easiest way.

Jessé Cruz — Mon, 07 Sep 2026 12:02:05 +0000

Need a private npm registry without changing the way your team already works?

In this guide, I walk through setting up Omni Line as a self-hosted npm registry — from installation to publishing and installing private packages.

The workflow is intentionally simple:

Install Omni Line
Create a hosted npm registry
Generate a personal access token
Configure .npmrc
Keep using npm publish and npm install as usual
You can run it on your own infrastructure and use the same registry workflow for developers, CI, and even AI coding agents.

I also cover how to let an agent handle most of the setup while keeping package publishing explicit and controlled.

Read the full guide.