Google Artifact Registry - Store Your Docker Images and Packages

Google's replacement for Container Registry that doesn't suck as much. It's basically a fancy storage bucket for your Docker images, npm packages, and other build artifacts, but with Google's typical over-engineering.

What It Actually Does

Stores your Docker images, Maven jars, npm packages, Python wheels, Go modules, and Helm charts in one place. The main selling point is that it integrates with Google Cloud without making you want to throw your laptop out the window (most of the time).

Gotcha: If your project ID has underscores (like my_awesome_project), Docker daemon will randomly refuse to authenticate with a cryptic unauthorized: authentication required error. Had this weird auth issue at 2am during a deploy, took forever to figure out it was fucking underscores in the project ID. Docker expects proper hostname parsing and underscores break it. Stack Overflow was full of unhelpful just use service accounts responses.

You get three types of repositories:

• Standard repos: Your stuff
• Remote repos: Caches Docker Hub/npm registry so your builds don't break when those services have their weekly outage
• Virtual repos: Groups multiple repos so you only need one URL (because nobody wants to manage 15 different registry endpoints)

The Google Cloud Integration

Works with GKE, Cloud Run, and Compute Engine without the usual credential nightmare. Uses IAM for permissions, which is either great or terrible depending on how much you enjoy reading IAM documentation.

The authentication setup is actually pretty straightforward once you wrap your head around service accounts. Your CI/CD pipeline gets a service account, you give it the right permissions, and it just works. Until it doesn't, and then you spend 3 hours debugging why your builds suddenly can't push images.

Pro tip: Always run gcloud auth configure-docker --verbose when setting up auth or you'll spend hours debugging mystery Error response from daemon: Get https://gcr.io/v2/: unauthorized failures that make no fucking sense. The verbose flag shows exactly which auth configuration got missed - usually the registry endpoint isn't properly added to Docker's credential helper config.

Security Stuff

Built-in vulnerability scanning that actually finds things (unlike some other tools we won't name). Integrates with Binary Authorization if you're into that whole "policy enforcement" thing. VPC Service Controls keep your stuff locked down if you're paranoid about network security.

Reality check: The scanner caught a Log4j vulnerability in our base image that our previous tool missed completely. Saved us from the panic of 2021.

Artifact Registry is basically what Container Registry should have been from the start. Container Registry is in maintenance mode now, so migrate before Google kills it like they kill everything else.

Here's the technical shit that actually matters:

Supported Formats (AKA What You Can Actually Store Here)

Docker images (obviously), Maven jars for Java, npm packages for Node.js, Python packages, Go modules, and Helm charts. Also supports Apt and Yum packages if you're still managing Linux repos manually like it's 2010.

Each format works with existing toolchains, so you don't have to rewrite your entire build pipeline. Docker CLI works normally, npm/pip/maven all work as expected. The only thing that changes is the registry URL.

Warning: Go module proxies are fucking finicky with private registries. If you get go: reading https://proxy.golang.org/...: 410 Gone errors, you need to add GOPRIVATE=us-docker.pkg.dev (or whatever your registry URL is) to your environment or Go will keep trying to fetch your private modules from the public proxy. Spent 4 hours debugging this when Go 1.19 started enforcing the module proxy by default and our CI builds randomly started failing.

Repository Types (Because Google Loves Options)

Standard repositories: Where your code lives after CI builds it. You can have multiple repos per project, which is great until you forget which one contains what.

Remote repositories: The killer feature. These cache Docker Hub, Maven Central, npm registry, etc. No more builds failing because Docker Hub is down again (happens more than you'd think). Cached stuff stays available even when upstream services are having their monthly meltdown.

Virtual repositories: Combine multiple repos behind one URL. Sounds great in theory, priority ordering can be confusing when you have the same package in multiple places.

Fun fact: Virtual repo priority is fucked if you don't set it explicitly. We had builds pulling node:14.18.1 instead of node:16.17.0 because the priority defaulted to alphabetical instead of latest. Always specify priority order in the console or suffer mysterious version conflicts that make no sense.

Security Features (The Stuff That Actually Matters)

Vulnerability scanning that uses real CVE databases, not some proprietary nonsense. Scans both your application code and the base images you're building on. Results show up in Security Command Center if you use that.

Container scanning hits both OS packages and application dependencies. Custom policies let you define what "too risky" means for your org (spoiler: everything is too risky).

Supply chain security includes build provenance and SLSA compliance, because apparently we need acronyms for "track where your code came from."

Real talk: The scanner found like 800+ vulnerabilities in our "hardened" Alpine base image. Turns out "hardened" just means "different set of problems."

Performance (Will It Be Slow?)

Uses Google's global network, so download speeds are decent. Multi-regional repos replicate automatically, which reduces latency if you have teams everywhere.

Auto-scaling means it handles traffic spikes without you having to capacity plan. Deduplication saves money when you have 47 slightly different Node.js containers that all use the same base image.

Put your repos in the same region as your compute stuff to avoid data transfer charges and latency. Cross-region replication is available for disaster recovery, but you pay for the bandwidth.

Performance reality: Our 2GB Docker image pulls in 30 seconds from the same region, 2 minutes cross-continent. Not amazing, but not terrible either.

OK, pricing time - before your CFO starts asking uncomfortable questions.

Cost Structure (The Money Part)

Storage costs $0.10 per GB per month after 0.5 GB free. Data transfer within the same region is free, cross-region costs depend on distance ($0.01 to $0.15 per GB).

Reality check: Storage costs add up fast if you keep old images around. Set up retention policies or you'll get a surprise bill. Vulnerability scanning costs extra through Artifact Analysis - about $0.26 per image scan as of December 2024.

Horror story: We got hit with some massive bill one month - I think it was like $3,100 or something crazy - because nobody set up retention policies and we had like 18 months of nightly builds sitting there. Something like 40-50 services with monthly builds, maybe 1GB+ per image. That $0.10/GB adds up to real money fast when you're not paying attention.

Cost optimization tips:

• Delete old images regularly (retention policies are your friend)
• Use remote repos to cache public images instead of copying everything
• Keep repos in the same region as your compute resources
• Don't enable scanning on every single image if you're cost-conscious

Enterprise Integration (For The Big Companies)

Most organizations create separate repos for dev/staging/prod, or per-team, or per-application. There's no "right" way, but whatever you choose, document it before people start creating repos randomly.

IAM integration works with your existing Google Cloud setup. Service accounts handle CI/CD access. The permissions model is flexible enough to lock things down properly if your security team cares about that stuff.

VPC Service Controls prevent data exfiltration if you're paranoid about network security. Audit logging captures everything for compliance reasons.

Learn from our pain: Start with broad repo structure and narrow it down. We initially created one repo per microservice - I think we had like 40-50 repos or something insane - and it became a management nightmare. Now it's one repo per environment per team. Much saner.

Real-World Use Cases

Financial Services: Use vulnerability scanning and SLSA compliance to keep regulators happy. Regional repos help with data residency requirements.

Healthcare: VPC Service Controls and private connectivity for HIPAA compliance. Container scanning helps identify security issues before they hit production.

Gaming: Multi-regional repos reduce game update download times globally. Good for large binary assets.

SaaS Companies: Separate repos per customer or environment. Vulnerability scanning catches issues before they hit customer deployments.

Startup reality: Most startups just need one repo with retention policies. Don't over-engineer this shit until you actually need it.

Migration (Getting Your Stuff Here)

Docker Registry API v2 compatibility means you can migrate from Docker Hub, AWS ECR, or self-hosted registries without changing client configs. Just update the registry URL.

Container Registry users get automated migration tools. You can do gradual transitions instead of big-bang migrations.

Performance is best when repos are in the same region as your compute resources. Multi-regional repos help global teams but cost more.

Training is minimal if your team already knows Docker/npm/maven. Google's docs are actually decent for once.

Migration gotcha: Container Registry shutoff is March 18, 2025. If you're still pushing to gcr.io, migrate now or your builds will start throwing 403 Forbidden errors when they pull the plug. No grace period, no warnings - just broken builds.

The business case usually comes down to: does the convenience and reduced operational overhead justify the cost? For most teams not running massive container infrastructures, the answer is probably yes.