Oracle Cloud Artifact Registry Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute

1. Introduction

Oracle Cloud Artifact Registry is Oracle Cloud Infrastructure (OCI)’s managed service for storing and distributing software artifacts—most commonly container images used by Compute workloads (VMs, Kubernetes, Functions, CI/CD runners).

Simple explanation: Artifact Registry is a secure, centralized “warehouse” for the build outputs your applications need at runtime—so your servers and clusters can reliably pull the right container image or package version whenever they deploy.

Technical explanation: Artifact Registry provides regional, compartment-scoped repositories that support standards-based distribution protocols (for example, Docker Registry HTTP API v2 for container images). It integrates with OCI Identity and Access Management (IAM) for authorization, with OCI Audit for control-plane visibility, and with common OCI compute services such as Compute instances and Container Engine for Kubernetes (OKE) for image pulls.

What problem it solves: In modern delivery pipelines, application releases produce artifacts (images, charts, packages) that must be stored, versioned, secured, and delivered quickly to runtime environments. Without a managed registry, teams end up with inconsistent builds, ad-hoc storage, manual access control, slow pulls, and higher operational burden. Artifact Registry addresses these issues with a managed, IAM-integrated registry built for OCI.

Naming note (important): OCI historically referred to its container registry as OCI Registry (OCIR) and still uses the ocir.io domain in endpoints. Artifact Registry is the current service name in OCI Console and documentation. If you see OCIR in older guides, it typically refers to the same family of capabilities. Verify current naming and features in the official docs linked in Section 17.

2. What is Artifact Registry?

Official purpose: Artifact Registry is OCI’s service for hosting and managing software artifacts—especially container images—so teams can push artifacts from build systems and pull them from runtime environments in a controlled, auditable way.

Core capabilities (commonly used): – Create and manage repositories in OCI compartments – Push and pull container images using standard Docker/OCI tooling – Control access with OCI IAM policies – Organize artifacts by repository and tags (and/or digests) – Integrate artifacts into OCI deployment targets (Compute, OKE, DevOps)

Major components: – Tenancy namespace: A unique identifier used as part of image names and endpoints (commonly required when tagging images for OCI). – Repositories: Logical collections of artifacts (for example, a repository per application or per team). – Artifacts: The stored items (commonly container image manifests/layers). – Tags and digests: Human-friendly pointers (tags) and immutable identifiers (digests) used to reference images.

Service type: Managed registry service (control plane via OCI APIs/Console; data plane via registry endpoints).

Scope and placement: – Regional service: Repositories exist in a specific OCI region. Your clients push/pull from the region endpoint (for example, a *.ocir.io host). – Tenancy + compartment-scoped management: Administrative control is governed by IAM policies in compartments within a tenancy. – Network access: Typically accessed over HTTPS via a public endpoint; private network patterns depend on OCI networking options and service capabilities in your region (verify in official docs).

How it fits into the Oracle Cloud ecosystem (especially Compute): – Compute instances pull images to run containerized workloads (Docker/Podman). – OKE pulls images to schedule containers on Kubernetes nodes. – OCI DevOps build pipelines push images; deploy pipelines reference them. – IAM defines who can create repos, push images, and pull images. – Audit records management actions (for example, repo creation/deletion). Data-plane logging (image pull/push events) varies—verify in docs for your exact needs.

3. Why use Artifact Registry?

Business reasons

Faster, repeatable releases: Centralized artifacts reduce “works on my machine” drift and improve deployment consistency.
Reduced operational overhead: Managed service eliminates running your own registry infrastructure and patching it.
Cleaner governance: Repository organization by compartment supports business unit/team separation.

Technical reasons

Standards-based tooling: Works with Docker-compatible clients and common CI systems.
Regional proximity: Hosting artifacts in the same region as runtime Compute reduces pull latency and improves rollout speed.
Immutable references (via digests): Supports safer deployments by pinning exact image digests (where your tooling supports it).

Operational reasons

OCI-native IAM: Use groups, dynamic groups, and policies for consistent access control.
Compartment model: Align repositories with environments (dev/test/prod) and teams.
Automation-friendly: Manage repos and images via OCI APIs/CLI (verify command set in your OCI CLI version).

Security / compliance reasons

Least privilege access: Separate who can push vs. who can pull.
Auditability (control plane): Administrative actions can be tracked via OCI Audit.
Encryption-at-rest and TLS-in-transit: OCI services generally encrypt data at rest and use TLS for transport; confirm specifics in Artifact Registry docs for your compliance baseline.

Scalability / performance reasons

Designed for many pulls: Registries are optimized for distributing images to fleets of nodes.
Supports modern delivery patterns: Blue/green or canary rollouts involve many concurrent pulls; a registry is the correct distribution primitive.

When teams should choose Artifact Registry

You deploy workloads to OCI Compute or OKE and need a reliable image source.
You want OCI IAM governance rather than separate credentials per tool.
You want to keep artifacts close to OCI regions to reduce latency and egress.

When teams should not choose it

You are not using OCI for runtime and already standardize on another registry with strong cross-cloud replication (unless you implement a multi-registry strategy).
You require features not confirmed for OCI Artifact Registry in your region (for example, advanced replication policies, native pull-through caching, or specific signing workflows). In those cases, validate capabilities first or use an alternative such as JFrog Artifactory or Harbor.

4. Where is Artifact Registry used?

Industries

SaaS and software companies running microservices on Kubernetes
Finance and regulated industries needing compartment-based controls and auditability
Retail/e-commerce with bursty scaling events requiring rapid image pulls
Telecom and media workloads with frequent deployments and CI/CD maturity

Team types

Platform engineering teams building internal developer platforms on OCI
DevOps/SRE teams standardizing delivery pipelines
Security teams implementing artifact provenance and access controls
Application teams packaging services into containers

Workloads

Containerized web APIs and background workers
Batch processing jobs on Compute instances
Kubernetes workloads on OKE (Deployments, CronJobs, Jobs)
Serverless (Functions) image-based deployments (verify current OCI Functions packaging model in your region)

Architectures

Single-region production with dev/test compartments
Multi-region DR designs (artifact strategy depends on supported replication approaches—verify)
Microservices with one repo per service
Monorepos with multi-image builds and version tagging

Production vs dev/test usage

Dev/test: frequent pushes, many tags, rapid churn; cost and cleanup hygiene matter.
Production: fewer pushes, controlled promotion, strong access controls, digest pinning, and change management.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Artifact Registry fits well.

1) Central container image store for Compute-based apps

Problem: VMs run containers, but images are scattered across laptops and ad-hoc servers.
Why it fits: Artifact Registry provides a managed, IAM-controlled registry endpoint.
Example: A team runs 20 OCI Compute instances that pull myapi:1.4.2 during rollout.

2) Kubernetes (OKE) cluster image source

Problem: Kubernetes nodes must pull images quickly and securely.
Why it fits: OKE can pull images from OCI’s registry endpoints using standard image references.
Example: A production OKE cluster pulls images from a “prod” compartment repository.

3) CI pipeline push target for built images

Problem: CI builds container images but needs a trusted place to push them.
Why it fits: CI runners can authenticate and push to Artifact Registry; deploy stages pull the same artifact.
Example: OCI DevOps build pipeline pushes orders:2026.04.16.1 after tests pass.

4) Environment separation by compartment (dev/test/prod)

Problem: Developers accidentally deploy dev images to production.
Why it fits: Use separate compartments and IAM policies; prod repos are write-protected.
Example: Only a release automation group can push to the prod repo.

5) Third-party vendor image distribution inside OCI

Problem: Vendor provides a container image, but you need to host it internally for controlled pulls.
Why it fits: Pull vendor image once, retag, and push into your OCI-controlled repository.
Example: Security scans and approvals happen before pushing vendor/agent:3.2.

6) Rollbacks with immutable image digests

Problem: Tag-based deployments can drift if tags are overwritten.
Why it fits: Deploy by digest (image@sha256:...) for deterministic rollback behavior.
Example: A release references the digest used in the previous stable deploy.

7) Multi-team platform registry with standardized naming

Problem: Teams use inconsistent naming, causing confusion and broken automation.
Why it fits: Define conventions by repo structure and tagging strategy.
Example: ocir.io/<ns>/team-app/service:semver-build.

8) Controlled distribution to air-gapped-ish subnets (egress-restricted)

Problem: Compute nodes in private subnets cannot reach public registries.
Why it fits: Hosting artifacts in OCI reduces external dependencies; network egress design can be standardized (NAT/service routing—verify options).
Example: Private OKE nodes pull from OCI endpoints through approved egress paths.

9) Blue/green deployments that require fast, parallel pulls

Problem: A rollout doubles the number of nodes pulling images at once.
Why it fits: Registry services are designed for concurrent distribution patterns.
Example: 200 pods pull a new image in minutes during traffic shift.

10) “Golden base image” program

Problem: Security team wants standardized base images patched regularly.
Why it fits: Store base images in a controlled repo; app teams inherit from them.
Example: base/oraclelinux:9-secured-2026w15 is the approved baseline.

11) Disaster recovery preparedness for container artifacts

Problem: You can recreate infra, but you also need the exact images used in production.
Why it fits: A registry is a source of truth for runtime artifacts (multi-region strategy depends on available replication/export methods—verify).
Example: DR runbook includes pulling production-tagged images to rebuild services.

12) Migration from self-hosted registry to OCI-managed

Problem: Self-hosted registry maintenance and outages affect deployments.
Why it fits: Move images to Artifact Registry and simplify operations.
Example: Migrate from a VM-hosted Docker registry to OCI repositories, update image references.

6. Core Features

The exact feature set can vary over time and by OCI region. Use this section as a practical baseline and verify advanced features (replication, retention, scanning, signing) in the official docs before relying on them.

1) Managed repositories for container images

What it does: Hosts OCI/Docker container images and serves them to clients.
Why it matters: Containers are the standard packaging unit for modern Compute and Kubernetes workloads.
Practical benefit: No need to run/patch your own registry servers.
Caveats: Repository types and supported artifact formats can evolve—verify supported formats in your tenancy/region.

2) Standards-based push/pull with Docker-compatible tooling

What it does: Supports typical workflows: docker login, docker push, docker pull.
Why it matters: Minimal changes to existing developer and CI practices.
Practical benefit: Easy onboarding for teams used to Docker Hub, ECR, GCR, ACR.
Caveats: Authentication uses OCI constructs (namespace, auth tokens) that differ from other clouds.

3) Compartment-based organization

What it does: Lets you place repositories into compartments for isolation and governance.
Why it matters: Compartments are OCI’s core boundary for access control and resource organization.
Practical benefit: Clean dev/test/prod separation and chargeback.
Caveats: Cross-compartment access requires explicit IAM policies.

4) IAM policy-based access control

What it does: Controls who can manage repositories and who can read/pull artifacts.
Why it matters: Artifact access is production access. Pull rights effectively grant code execution capability.
Practical benefit: Enforce least privilege and separation of duties.
Caveats: Precise policy verbs/resource types should be confirmed in official docs for Artifact Registry.

5) Tenancy namespace integration

What it does: Uses your tenancy’s unique namespace as part of artifact addressing.
Why it matters: Prevents naming collisions and scopes registry identities.
Practical benefit: Clear ownership and stable naming across OCI.
Caveats: Namespace is required in image names; mis-typing it is a common cause of auth failures.

6) Tagging and versioning conventions

What it does: Lets you label images with tags (:1.0.3, :prod, :gitsha-...) and reference immutable digests.
Why it matters: Good tag strategy reduces rollback risk and deployment confusion.
Practical benefit: You can implement promotion flows (build tag → release tag → prod tag).
Caveats: Tags are mutable by nature; use digests for strict immutability.

7) API/Console/CLI manageability

What it does: Offers multiple management planes (Console UI and API). OCI CLI commonly supports Artifact Registry operations.
Why it matters: Enables automation and Infrastructure as Code patterns.
Practical benefit: Script repo creation, cleanup jobs, and CI bootstrap.
Caveats: Verify the exact OCI CLI command group for your installed CLI version (for example, run oci --help and search for “artifacts” / “registry”).

8) Integration with OCI DevOps (common pattern)

What it does: CI builds push images; CD deploys workloads that pull those images.
Why it matters: Registry becomes the bridge between build and runtime.
Practical benefit: Clear promotion model; fewer “artifact lost” issues.
Caveats: Exact integration steps depend on DevOps pipeline type and auth model—verify in DevOps docs.

9) Auditing via OCI Audit (control plane)

What it does: Records management operations (create/update/delete repo, policy changes, etc.) in OCI Audit.
Why it matters: Supports governance and incident investigations.
Practical benefit: You can track “who changed repo settings and when.”
Caveats: Data-plane events (every pull/push) may not be fully captured; validate logging requirements early.

7. Architecture and How It Works

High-level architecture

Artifact Registry sits between: – Producers (developers, CI build agents) that push artifacts, and – Consumers (Compute instances, OKE nodes, deployment systems) that pull artifacts.

The registry control plane is managed through OCI (Console/API), while the data plane uses the registry endpoint over HTTPS.

Request/data/control flow (typical)

Admin creates a repository in a compartment (Console/API).
IAM policy grants push/pull permissions to a group or dynamic group.
CI or developer workstation authenticates and pushes an image to the regional endpoint.
Runtime (Compute/OKE) authenticates and pulls the image by tag or digest.
Deployments run the image; rollouts reference tags/digests.

Integrations with related OCI services

Compute: pull/run images on VMs
OKE: image pulls for pods
OCI DevOps: build and deploy pipelines referencing registry artifacts
IAM: groups, dynamic groups, policies
Vault: store secrets (for example, registry auth tokens) used by CI systems
Audit: track administrative operations

Dependency services (conceptual)

OCI IAM for authorization
OCI networking for connectivity to endpoints (VCN egress for private subnets)
OCI compartments for governance boundaries

Security/authentication model (common patterns)

Human users often authenticate to the registry with an auth token generated in OCI (rather than using the console password). Docker then stores the token locally.
Automation (CI/CD) also typically uses auth tokens stored in a secret manager (Vault or a CI secret store).
Workloads (Compute/OKE) generally use image pull secrets or node-level credentials depending on orchestration approach.

Verify the recommended authentication method for your exact OCI setup (native IAM users vs federated identities) in the official docs, because username formats can differ.

Networking model (practical)

Artifact Registry is accessed over HTTPS using a region-specific host (commonly REGIONKEY.ocir.io).
Compute resources in private subnets need an outbound path to reach the registry endpoint (commonly via NAT gateway). Whether a Service Gateway/private routing is supported for Artifact Registry depends on OCI service endpoint design—verify in official networking docs and Artifact Registry docs.

Monitoring/logging/governance considerations

OCI Audit: monitor control-plane actions and policy changes.
Tagging: use OCI resource tags on repositories for cost allocation.
Quotas/service limits: define/monitor repository and storage usage; validate rate/size limits for large images.

Simple architecture diagram

flowchart LR
  Dev[Developer / CI Runner] -->|docker push (HTTPS)| AR[OCI Artifact Registry<br/>Regional Endpoint]
  AR -->|docker pull (HTTPS)| VM[OCI Compute Instance]
  VM --> App[Running Container Workload]
  IAM[OCI IAM Policies] -. authorizes .- Dev
  IAM -. authorizes .- VM

Production-style architecture diagram

flowchart TB
  subgraph CICD[CI/CD]
    Git[Source Repo] --> Build[Build Pipeline<br/>tests + docker build]
    Build -->|push image| AR[OCI Artifact Registry<br/>Prod Region]
  end

  subgraph OCI[Oracle Cloud (OCI)]
    IAM[OCI IAM<br/>Groups/Dynamic Groups/Policies]
    Vault[OCI Vault<br/>Secrets (auth token)]
    Audit[OCI Audit]
    VCN[VCN]
    NAT[NAT Gateway / Egress Path]
    OKE[OKE Cluster<br/>Worker Nodes in Private Subnets]
    Deploy[Deploy Pipeline<br/>or GitOps Controller]
  end

  Vault --> Build
  IAM -.authz.- Build
  IAM -.authz.- Deploy
  Audit -.logs.- AR

  Deploy --> OKE
  OKE -->|pull image via egress| NAT --> AR

8. Prerequisites

Account/tenancy requirements

An active Oracle Cloud tenancy with permissions to use Artifact Registry in at least one region.
A compartment to hold your repository (or permission to create one).

Permissions / IAM roles

You need permissions to: – Create/manage Artifact Registry repositories in a compartment – Read/pull artifacts (for runtime validation) – Create auth tokens for a user (for Docker login)

In many organizations, these are covered by an admin role. If you are not an admin, ask your OCI administrator to grant the minimum required permissions for Artifact Registry. Verify the exact IAM policy syntax for Artifact Registry in official docs, because policy verbs/resource types must match OCI’s authorization model.

Billing requirements

Artifact storage and data transfer may incur charges depending on your usage and Free Tier allowances (see Section 9).

Tools needed

Docker (or Podman with Docker-compatible workflow) on your local machine
Optional: OCI CLI for automation (verify your CLI supports Artifact Registry commands)
Optional: SSH client if you will validate from an OCI Compute instance

Region availability

Artifact Registry is region-based. Choose a region where your tenancy is subscribed and where you run Compute/OKE.

Quotas/limits

Repository count limits, storage limits, and request limits can apply.
Check Service Limits in OCI Console and the Artifact Registry docs for current quotas.

Prerequisite services (for the lab)

OCI Compute (to validate pulling and running the container on a VM)
VCN networking to access the VM via SSH (public IP for simplest lab)

9. Pricing / Cost

Artifact Registry costs are typically driven by storage and network egress, plus any related costs from build and runtime environments.

Pricing dimensions (model overview)

Common pricing factors include: – Stored data (GB-month): Container image layers and manifests stored in the registry. – Data transfer out (egress): Pulling images out of a region or out to the public internet can incur egress charges depending on OCI networking rules and destination. – Requests/operations: Some registries price by API operations; OCI’s exact model must be confirmed on the official pricing page for Artifact Registry/Registry.

Because OCI pricing can vary by region and may be updated, do not rely on third-party numbers. Always confirm with Oracle’s official sources: – OCI pricing pages: https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html
– OCI Pricing documentation (if provided per service in your region): verify in official docs.

Free Tier (if applicable)

Oracle Cloud has an Always Free and Free Trial program. Whether Artifact Registry storage/egress is included or discounted depends on current Free Tier terms. Verify Free Tier coverage for Artifact Registry and related services in your account.

Primary cost drivers

Image size: Large base images (language runtimes, ML stacks) amplify storage and pull costs.
Number of tags/versions kept: Keeping every build forever increases storage steadily.
Pull frequency: Auto-scaling clusters pull images repeatedly unless nodes cache them.
Cross-region pulls: Pulling from a different region can add latency and potential inter-region data transfer costs.

Hidden or indirect costs

Compute build minutes: CI builds running on Compute instances or DevOps build runners cost money.
OKE node egress: Private nodes pulling images may require NAT gateway usage; NAT itself has costs and egress charges may apply.
Backup/DR strategy: If you export images for DR (for example, to Object Storage), that adds storage and transfer costs.

Network/data transfer implications

Pulling images within the same region where the workloads run is typically the most cost-efficient and performant pattern.
Pulling images to on-prem or another cloud can create internet egress charges.
If you run private subnets, egress architecture (NAT/service routing) impacts cost.

How to optimize cost (practical)

Keep images small: multi-stage builds, minimal base images.
Limit tag retention: remove old CI tags; keep only releases.
Prefer same-region artifact placement as runtime.
Avoid needless repulls: use node-level caching and stable tags/digests; avoid :latest in production.
Promote images by retagging release candidates rather than rebuilding identical layers repeatedly.

Example low-cost starter estimate (no fabricated prices)

A realistic starter monthly footprint might look like: – 5 services × 2 images each × 300 MB per image average ≈ 3 GB stored – 10 pulls per day per service in dev/test ≈ moderate data transfer

Cost will be: – storage_GB_month × storage_rate + egress_GB × egress_rate (if applicable)

Use the OCI Cost Estimator to plug your region and expected GB-month and egress.

Example production cost considerations

In production: – 50–200 nodes pulling images during deployments can create bursty data transfer. – Retaining 6–12 months of releases can build significant GB-month usage. – Multi-region strategies can multiply storage if you keep copies per region.

10. Step-by-Step Hands-On Tutorial

Objective

Create an Artifact Registry repository in Oracle Cloud, push a Docker image from your laptop, then pull and run that image on an OCI Compute instance.

This lab is designed to be: – Beginner-friendly – Low-cost (uses small images and a single VM) – Realistic (mirrors common CI/CD workflows)

Lab Overview

You will: 1. Identify your tenancy’s namespace and registry endpoint. 2. Create an Artifact Registry repository. 3. Generate an auth token and log in to the registry using Docker. 4. Build a small container image and push it to Artifact Registry. 5. Provision a Compute VM, pull the image, and run the container. 6. Validate and clean up.

Step 1: Choose region, compartment, and find your registry namespace

Actions (OCI Console): 1. Sign in to Oracle Cloud Console. 2. Select the region you will use (top-right region selector). 3. Go to Developer Services → Artifact Registry (service name may appear under Developer Services). 4. Find the Namespace value (often shown in the Artifact Registry/Registry settings area).

Expected outcome: – You have the tenancy namespace string (you will use it in the image name). – You know your region key (example format: iad, fra, lhr), which is typically part of the registry endpoint.

Notes: – OCI registry endpoints commonly look like:
REGIONKEY.ocir.io
The image name commonly includes:
REGIONKEY.ocir.io/NAMESPACE/REPOSITORY/IMAGE:TAG

Because endpoint formats can change or differ by realm, verify the exact endpoint shown in the OCI Console for Artifact Registry.

Step 2: Create an Artifact Registry repository

Actions (OCI Console): 1. Go to Developer Services → Artifact Registry. 2. Select your target compartment (left-side compartment selector). 3. Click Create repository. 4. Choose the repository format/type appropriate for container images. 5. Name the repository (example): hello-repo 6. Create it.

Expected outcome: – A repository named hello-repo exists in your compartment.

Verification: – You can see the repository in the Artifact Registry repository list.

Step 3: Create an auth token for Docker login

OCI commonly uses auth tokens for registry access from Docker/CI.

Actions (OCI Console): 1. Go to Identity & Security → Users. 2. Select your user. 3. Find Auth Tokens and click Generate Token. 4. Give it a description (example: docker-login-lab). 5. Copy the token value immediately and store it securely (you won’t be able to view it again).

Expected outcome: – You have an auth token string saved securely for the next steps.

Security tip: Treat the auth token like a password. Don’t paste it into chat logs or commit it to Git.

Step 4: Log in to Artifact Registry from your local machine

You will now use Docker to authenticate to the OCI registry endpoint.

Identify these values: – REGIONKEY: for example iad (use your actual region key) – NAMESPACE: your tenancy namespace – USERNAME: your OCI username.
For federated identities, the username format may differ (for example, it may include an identity provider prefix). Verify the required username format in the official Artifact Registry docs for your identity type.

Command:

export REGIONKEY="your-region-key"
export NAMESPACE="your-namespace"
export USERNAME="your-oci-username"

docker logout "${REGIONKEY}.ocir.io" || true
docker login "${REGIONKEY}.ocir.io" -u "${NAMESPACE}/${USERNAME}"

When prompted for a password, paste the auth token.

Expected outcome: – Docker reports Login Succeeded.

Verification:

docker system info | grep -i -A2 "Registry"

And/or check ~/.docker/config.json for an auth entry (do not share it).

Common error: unauthorized: authentication required – Re-check region endpoint (REGIONKEY.ocir.io) – Re-check namespace and username format – Ensure you pasted the auth token (not your console password) – Confirm your user/group has permission to push/pull (IAM policy)

Step 5: Build a small Docker image locally

Create a new folder and add a tiny web server container.

Commands:

mkdir -p artifact-registry-lab && cd artifact-registry-lab
cat > app.py <<'EOF'
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-type", "text/plain; charset=utf-8")
        self.end_headers()
        self.wfile.write(b"Hello from OCI Artifact Registry on Oracle Cloud Compute!\n")

HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()
EOF

cat > Dockerfile <<'EOF'
FROM python:3.12-slim
WORKDIR /app
COPY app.py /app/app.py
EXPOSE 8080
CMD ["python", "/app/app.py"]
EOF

docker build -t hello-artifact:1.0 .

Expected outcome: – Docker successfully builds the image hello-artifact:1.0.

Verification:

docker images | grep hello-artifact
docker run --rm -p 8080:8080 hello-artifact:1.0

In a second terminal:

curl -s http://localhost:8080

Stop the container with Ctrl+C.

Step 6: Tag and push the image to Artifact Registry

Construct your full image name. A common pattern is:

REGIONKEY.ocir.io/NAMESPACE/REPO/IMAGE:TAG

Example (yours will differ): – iad.ocir.io/mytenancyns/hello-repo/hello-artifact:1.0

Commands:

export REPO="hello-repo"
export IMAGE="hello-artifact"
export TAG="1.0"

export FULL_IMAGE="${REGIONKEY}.ocir.io/${NAMESPACE}/${REPO}/${IMAGE}:${TAG}"

docker tag hello-artifact:1.0 "${FULL_IMAGE}"
docker push "${FULL_IMAGE}"

Expected outcome: – Docker outputs layer upload progress and finishes with a digest line.

Verification (OCI Console): – Go to Artifact Registry → Repositories → hello-repo – Confirm the image/tag appears.

Common error: denied: requested access to the resource is denied – Repository path mismatch (wrong repo name in the image reference) – IAM policy does not allow pushing – Wrong namespace/username/token

Step 7: Create a small OCI Compute instance for validation

For a minimal-cost validation: – Use an Always Free–eligible shape if available in your region (availability varies—verify in console). – Use Oracle Linux (common default).

Actions (OCI Console): 1. Go to Compute → Instances → Create instance 2. Choose: – Name: artifact-registry-vm – Image: Oracle Linux (current supported version) – Shape: small shape (Always Free if available) 3. Networking: – Create/choose a VCN and subnet – Assign a public IPv4 address (simplest for a lab) 4. Add your SSH public key 5. Create

Expected outcome: – Instance is running and has a public IP.

Verification: – SSH to the instance:

ssh -i /path/to/private_key opc@PUBLIC_IP

Step 8: Install Docker (or Podman) on the VM

Oracle Linux commonly supports Podman by default; Docker may require extra steps. Choose one approach that is supported for your OS version.

Option A (Podman): (often easiest on modern Oracle Linux)

sudo dnf -y install podman
podman --version

Option B (Docker): Follow the current Oracle Linux + Docker installation instructions for your OS version. Because package availability changes, verify in official Oracle Linux docs.

For the remainder of the lab, we’ll show Docker commands. If you use Podman, many commands are the same (podman login, podman pull, podman run).

Step 9: Log in from the VM and pull the image

On the VM, authenticate to the registry.

Command (Docker):

export REGIONKEY="your-region-key"
export NAMESPACE="your-namespace"
export USERNAME="your-oci-username"
export FULL_IMAGE="${REGIONKEY}.ocir.io/${NAMESPACE}/hello-repo/hello-artifact:1.0"

docker login "${REGIONKEY}.ocir.io" -u "${NAMESPACE}/${USERNAME}"
docker pull "${FULL_IMAGE}"

Paste the same auth token as the password.

Expected outcome: – The image pulls successfully.

Verification:

docker images | grep hello-artifact

Step 10: Run the container and validate it

Run the container on port 8080 and confirm it responds.

Commands (on the VM):

docker run -d --name hello-oci -p 8080:8080 "${FULL_IMAGE}"
docker ps | grep hello-oci
curl -s http://localhost:8080

Expected outcome: – curl prints:
Hello from OCI Artifact Registry on Oracle Cloud Compute!

To test from your laptop, open the instance’s security list / NSG to allow inbound TCP 8080 from your IP, then:

curl -s http://PUBLIC_IP:8080

Verification:

docker logs hello-oci --tail 20

Validation

You have successfully validated: – Repository creation in Oracle Cloud Artifact Registry – Docker authentication using OCI auth token – Image push from local workstation – Image pull and run on OCI Compute

Checklist: – [ ] Image tag visible in the OCI Console repository – [ ] docker push completes without permission errors – [ ] VM can docker pull the same image – [ ] Container responds on http://localhost:8080 (and optionally via public IP)

Troubleshooting

1) Docker login fails – Confirm endpoint: REGIONKEY.ocir.io – Confirm username format: NAMESPACE/USERNAME (federated users may differ; verify) – Use auth token (not console password) – Ensure IAM policies allow access

2) Push denied – Ensure repository exists and name matches exactly – Ensure your user/group can push/manage artifacts in that compartment – Ensure you are pushing to the correct region endpoint

3) VM cannot pull (timeout) – If VM is in private subnet, ensure it has egress (NAT gateway + route rules) – Check DNS resolution on VM – Verify security rules allow outbound HTTPS

4) Container runs but not reachable from laptop – Open inbound TCP 8080 in NSG/security list for your source IP – Confirm firewall on the VM (Oracle Linux firewall rules) – Confirm docker run -p 8080:8080 published the port

Cleanup

To avoid ongoing costs: 1. Stop and remove container on VM

docker rm -f hello-oci || true

Optionally remove the image

docker rmi "${FULL_IMAGE}" || true

Terminate the Compute instance – OCI Console → Compute → Instances → artifact-registry-vm → Terminate
Delete the repository/images – Artifact Registry → repository → delete images/tags as needed, then delete repository
Revoke auth token – Identity & Security → Users → your user → Auth Tokens → delete the token

11. Best Practices

Architecture best practices

Keep artifacts in the same region as runtime to reduce latency and egress.
Use separate compartments for dev/test/prod repositories to reduce blast radius.
Reference production deployments by digest where possible for immutability.

IAM/security best practices

Separate push and pull permissions:
CI/build systems: push (write)
Runtime (OKE/Compute): pull (read)
Use least privilege policies per compartment.
Avoid sharing human auth tokens; use dedicated CI users or automation identities where possible.

Cost best practices

Implement retention hygiene: delete old CI tags and unused images.
Optimize image size: slim bases, multi-stage builds, reduce layers.
Avoid cross-region pulls unless required.

Performance best practices

Use stable base layers to maximize layer caching on nodes.
Avoid latest for anything beyond local dev.
Batch rollouts to prevent unnecessary repeated pulls in short windows (depends on your orchestrator).

Reliability best practices

Treat the registry as production infrastructure:
Define ownership
Document restore/migration approach (export images if needed—verify recommended method)
Plan for DR: decide whether you rebuild images from source or maintain artifact copies.

Operations best practices

Tag repositories with cost center, environment, owner.
Monitor storage growth and enforce cleanup policies via automation.
Use Audit logs for governance and incident response.

Governance/tagging/naming best practices

Repository naming:
team-app-service or org/team/service
Image tags:
semver for releases (e.g., 1.8.0)
gitsha-<shortsha> for traceability
build-<buildnumber> for CI
OCI tags on repos:
Environment=prod
Owner=platform-team
CostCenter=...

12. Security Considerations

Identity and access model

OCI IAM controls management and access to Artifact Registry resources through policies.
Docker clients commonly authenticate using auth tokens associated with users.
In Kubernetes, use image pull secrets and scope them carefully.

Key security principle: If an identity can push to a repo used by production, it can effectively introduce code that runs in production. Treat push permission as highly sensitive.

Encryption

OCI services typically encrypt data at rest and use TLS for in-transit encryption.
Confirm Artifact Registry’s encryption posture and any customer-managed key options (if needed) in official docs.

Network exposure

Registry endpoints are accessed via HTTPS.
Control egress from private subnets (NAT/service routing as applicable).
Restrict inbound access to workloads; don’t expose test containers to the internet unnecessarily.

Secrets handling

Store auth tokens in OCI Vault or your CI secret store.
Rotate tokens regularly and immediately on suspected compromise.
Avoid embedding tokens into VM images or container images.

Audit/logging

Enable and retain OCI Audit logs per your governance policy.
Track:
Repo creation/deletion
IAM policy changes
Token creation/deletion processes (token events visibility may vary—verify)

Compliance considerations

If you have compliance needs (SOC 2, ISO, PCI, HIPAA), confirm:
Data residency (region-specific)
Access logging detail
Retention controls
Encryption key management options

Common security mistakes

Using one shared “registry password” across teams
Allowing broad push access to prod repos
Deploying with mutable tags only (risk of tag overwrite)
Leaving old auth tokens active indefinitely
Pulling images directly from public registries in production without vetting

Secure deployment recommendations

Use dev/test repos for experimentation; promote to prod repos via controlled pipeline.
Use digest pinning for production rollouts.
Restrict who can create/delete repos and who can push to prod.
Consider integrating image scanning and provenance workflows if available in your environment (verify OCI services and integrations).

13. Limitations and Gotchas

Validate current limits and supported features in official docs; registries evolve quickly.

Known limitations / common gotchas

Region specificity: Repositories are tied to a region. Pulling across regions can add latency and may incur transfer costs.
Namespace confusion: Misunderstanding the tenancy namespace is a top cause of denied and unauthorized errors.
Federated username format: For SSO/federated identities, Docker username format can differ. Verify in official docs.
Mutable tags: Tags can be overwritten; use digests for immutable references.
Private subnet egress: OKE/Compute in private subnets must have outbound connectivity to the registry endpoint. If you assume Service Gateway works for all services, you may be surprised—verify.
Large image performance: Very large images slow deployments and inflate costs.
Audit coverage: Control-plane operations are typically audited; full data-plane pull/push logging may not meet strict forensics requirements without additional tooling (verify).
Cleanup complexity: Deleting tags/images may have rules; ensure you understand whether deleting a tag deletes the underlying manifest/layers or just the reference (verify behavior in docs).

Quotas

Repository count, artifact count, and storage quotas can apply.
Check OCI Console Limits, Quotas and Usage and Artifact Registry limits documentation.

Migration challenges

Image naming changes (endpoint + namespace paths) require updates to deployment manifests.
Re-tagging strategies and CI scripts must be updated.
Access control differences vs. other registries require careful review.

14. Comparison with Alternatives

Nearest services in Oracle Cloud

OCI Object Storage: Can store files, but is not a Docker registry; lacks native container push/pull semantics.
OCI DevOps Artifacts/Deploy artifacts: DevOps pipelines may reference artifacts stored in different backends; Artifact Registry is purpose-built for container distribution.

Nearest services in other clouds

AWS Elastic Container Registry (ECR)
Google Artifact Registry
Azure Container Registry (ACR)

Open-source / self-managed alternatives

Harbor (popular enterprise registry)
JFrog Artifactory
Sonatype Nexus Repository
Docker Registry (open-source registry server)

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Artifact Registry	OCI-native container delivery	IAM + compartments, OCI integration, regional proximity to OCI Compute/OKE	Feature parity vs specialized registries depends on region/roadmap; cross-cloud patterns may require extra work	Your runtime is on Oracle Cloud and you want OCI-native governance
OCI Object Storage	Generic file storage	Durable object storage, lifecycle policies	Not a container registry; no native docker push/pull	Store non-registry artifacts or backups/exports
AWS ECR	AWS workloads	Deep AWS integration, mature ecosystem	Cross-cloud pulls can incur complexity/cost	Your runtime is on AWS
Google Artifact Registry	GCP workloads	Strong integration with GKE/Cloud Build	Not OCI-native	Your runtime is on GCP
Azure ACR	Azure workloads	Tight AKS/Azure DevOps integration	Not OCI-native	Your runtime is on Azure
Harbor (self-managed)	Enterprise control, on-prem/hybrid	Rich policy controls, can run anywhere	You operate and secure it; upgrades, storage, HA	You need on-prem/hybrid registry or custom controls
JFrog Artifactory	Large enterprises, multi-format	Broad artifact formats, enterprise workflows	Cost and operational complexity	You need one repo manager for many artifact types across clouds

15. Real-World Example

Enterprise example: regulated financial services on OCI + OKE

Problem: The organization runs microservices on OKE with strict separation between dev/test/prod and strong audit requirements. They want to prevent developers from pushing directly to production images.
Proposed architecture:
Artifact Registry repositories separated by compartment: dev, test, prod
OCI DevOps build pipeline pushes to dev repository
Promotion pipeline retags or copies approved images into prod repository (exact mechanism depends on supported operations—verify)
OKE production nodes only have pull access to prod
OCI Audit enabled for control-plane operations
Auth tokens stored in OCI Vault for CI use
Why Artifact Registry was chosen: OCI-native IAM and compartments align with enterprise governance and reduce the overhead of maintaining a self-hosted registry.
Expected outcomes:
Clear separation of duties (developers build; release engineering promotes)
Faster and more reliable deployments due to regional proximity
Improved traceability via standardized tags and controlled promotion

Startup/small-team example: single VM + lightweight containers

Problem: A small team deploys two containerized services to OCI Compute VMs. They want a simple, private place to store images without running their own registry server.
Proposed architecture:
One Artifact Registry repository per service
GitHub Actions (or OCI DevOps) builds and pushes images on each release
VM pulls images during deployment using a scoped auth token
Why Artifact Registry was chosen: Minimal operational burden and straightforward Docker compatibility.
Expected outcomes:
Repeatable deployments and quick rollback to prior tags
Reduced risk from pulling directly from public registries
Clean path to migrate to OKE later without changing the artifact source

16. FAQ

1) Is Artifact Registry the same as OCIR (OCI Registry)?
Artifact Registry is the current service name in OCI for registry capabilities, and many endpoints/workflows still reference ocir.io. Older documentation may use “OCIR.” Confirm current terminology and capabilities in the official docs.

2) Is Artifact Registry global or regional?
Artifact registries are typically regional in OCI. Create repositories in the region where you deploy Compute/OKE for best performance. Verify any cross-region options in official docs.

3) What can I store in Artifact Registry?
Most commonly container images. Other artifact formats (for example Helm charts or generic artifacts) may be supported—verify supported formats in the official documentation for your tenancy/region.

4) How do I authenticate Docker to OCI Artifact Registry?
Commonly via docker login REGIONKEY.ocir.io using NAMESPACE/USERNAME and an auth token as the password. Username formats can differ for federated identities—verify.

5) Should I use my OCI console password for Docker login?
Typically no. OCI commonly recommends auth tokens for registry access. Follow the official Artifact Registry authentication guide.

6) How should I name repositories?
Use a consistent convention: per team, per app, or per environment. Example: team-service, and enforce it with governance.

7) Should I deploy using image tags or digests?
Use digests for strict immutability in production where possible. Use tags for human readability and promotion flows.

8) Can OKE pull images from Artifact Registry automatically?
OKE can pull images from OCI registry endpoints, but authentication method depends on cluster/node setup and repository visibility. Configure imagePullSecrets where required.

9) Does Artifact Registry support vulnerability scanning?
OCI has security services that can scan container images in registries, but the exact integration and coverage should be confirmed in current official docs for your region and service versions.

10) How do I keep costs down?
Reduce image size, delete old tags, avoid storing every CI build forever, and keep pulls in-region.

11) Why do I get denied: requested access when pushing?
Usually wrong repo path, wrong namespace, or missing IAM permission. Confirm the repo exists in the selected compartment and your policy allows pushing.

12) Why do pulls work on my laptop but not from a private VM?
Private subnets need outbound HTTPS access. Ensure NAT/equivalent egress routing and DNS are correct.

13) Can I use Artifact Registry for non-container artifacts?
Possibly, depending on what artifact formats OCI supports in Artifact Registry at the time. Verify official docs for supported repository formats.

14) How do I implement dev/test/prod separation?
Use separate compartments and separate repositories, then lock down prod push rights to a release automation identity.

15) What’s the best way to rotate registry credentials?
Use dedicated tokens for CI and for runtime, store them in Vault/secret manager, rotate on a schedule, and revoke immediately on suspected compromise.

16) What happens when I delete a tag?
Behavior differs between registry implementations. It may remove only the tag reference or mark artifacts for garbage collection. Verify OCI’s deletion semantics before building cleanup automation.

17) Do I need OCI CLI to use Artifact Registry?
No. You can do everything with Console + Docker. CLI/API become useful for automation and repeatability.

17. Top Online Resources to Learn Artifact Registry

Resource Type	Name	Why It Is Useful
Official documentation	OCI Artifact Registry / Registry docs: https://docs.oracle.com/en-us/iaas/	Authoritative reference for repositories, auth, endpoints, limits
Official service docs (common path used historically)	OCI Registry documentation (may include Artifact Registry content): https://docs.oracle.com/en-us/iaas/Content/Registry/home.htm	Many workflows still reference OCIR endpoints and Docker usage
Official IAM docs	OCI IAM Overview: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	Understand policies, groups, dynamic groups, auth concepts
Official pricing	Oracle Cloud Price List: https://www.oracle.com/cloud/price-list/	Confirm current pricing dimensions for storage and egress
Official cost tool	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html	Build region-specific cost estimates without guessing numbers
Official Compute docs	OCI Compute docs: https://docs.oracle.com/en-us/iaas/Content/Compute/home.htm	VM setup for running/pulling container images
Official OKE docs	OCI Container Engine for Kubernetes: https://docs.oracle.com/en-us/iaas/Content/ContEng/home.htm	Kubernetes image pull patterns and cluster architecture
Official DevOps docs	OCI DevOps: https://docs.oracle.com/en-us/iaas/Content/devops/using/home.htm	CI/CD integration patterns with registries
Official security/audit docs	OCI Audit: https://docs.oracle.com/en-us/iaas/Content/Audit/home.htm	Governance and visibility into registry management operations
Trusted community	Oracle Cloud Infrastructure blog: https://blogs.oracle.com/cloud-infrastructure/	Practical announcements and implementation guidance (validate against docs)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	CI/CD, containers, cloud DevOps practices (verify OCI coverage)	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM, DevOps tooling, foundational practices	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops, monitoring, automation, operations practices	Check website	https://cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	SRE principles, incident response, observability	Check website	https://sreschool.com/
AiOpsSchool.com	Ops teams adopting AIOps	AIOps concepts, automation, event correlation	Check website	https://aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Engineers seeking guided training	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training services (verify OCI coverage)	DevOps beginners to advanced	https://devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training (verify scope)	Teams needing short-term expertise	https://devopsfreelancer.com/
devopssupport.in	DevOps support and guidance (verify services)	Ops teams needing practical help	https://devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify portfolio)	Architecture, migrations, CI/CD, ops	OCI container platform setup, registry governance model, pipeline hardening	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	Training + delivery support	Build-to-deploy pipelines using Artifact Registry, OKE deployment patterns, IAM best practices	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify services)	DevOps transformation and automation	Container standardization, secret management, rollout strategies	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

Docker fundamentals: images, layers, tags, registries
Basic OCI concepts: compartments, VCNs, IAM users/groups/policies
Compute basics: VM provisioning, SSH, firewall/security lists
CI fundamentals: build/test/publish steps

What to learn after this service

OCI DevOps pipelines (build and deploy)
OKE (Kubernetes) production operations
Secrets management with OCI Vault
Supply chain security: digest pinning, provenance, signing (depending on toolchain support)
Observability: logging/metrics for deployment pipelines and runtime

Job roles that use it

DevOps Engineer
Site Reliability Engineer (SRE)
Cloud Engineer (Oracle Cloud)
Platform Engineer
Kubernetes Administrator/Engineer
Security Engineer (cloud application security)

Certification path (if available)

Oracle’s certification offerings change over time. Look for: – OCI Architect/Developer/DevOps-related certifications on Oracle University (verify current certification titles and whether Artifact Registry is covered).

Project ideas for practice

Build a CI pipeline that pushes versioned images to Artifact Registry and deploys to a Compute VM.
Create an OKE deployment that pulls from a private repo using imagePullSecrets.
Implement an image retention cleanup script using OCI CLI/API (verify supported endpoints).
Design dev/test/prod compartment separation with least-privilege IAM policies.

22. Glossary

Artifact: A build output used for deployment (container image, chart, package).
Artifact Registry: OCI managed service for storing/distributing artifacts (commonly container images).
OCIR: OCI Registry; legacy/older naming often still used in endpoints (ocir.io).
Compartment: OCI logical container for resources and IAM access boundaries.
Tenancy namespace: Unique identifier used in OCI registry image names.
Repository (repo): A named collection of artifacts/images.
Tag: Human-readable label for an image version (:1.0.0, :prod).
Digest: Immutable cryptographic identifier for a specific image (@sha256:...).
Auth token: Token used as a password for registry authentication.
OKE: Oracle Container Engine for Kubernetes.
Egress: Outbound network traffic from a VCN/subnet to a service endpoint.
NAT gateway: OCI networking component enabling outbound internet access for private subnets.
Least privilege: Grant only the permissions required to perform a task.

23. Summary

Oracle Cloud Artifact Registry is OCI’s managed registry service for storing and distributing artifacts—most commonly container images that are pulled and run by Compute instances and OKE clusters. It matters because reliable artifact storage is a prerequisite for consistent CI/CD, safe rollouts, and scalable operations.

Architecturally, treat Artifact Registry as a regional dependency for your deployments: keep artifacts close to runtime, separate environments by compartments, and deploy production by digest when possible. Cost is primarily driven by stored GB-month and image pull/egress patterns—so reduce image size, control retention, and avoid unnecessary cross-region pulls. Security hinges on IAM: lock down push access to production repositories, protect auth tokens, and use audit logs for governance.

Next step: integrate Artifact Registry with an OCI DevOps build/deploy pipeline or an OKE cluster pull workflow, and formalize your tag/digest promotion strategy.

rajeshkumar

Category

1. Introduction

2. What is Artifact Registry?

3. Why use Artifact Registry?

Business reasons

Technical reasons

Operational reasons

Security / compliance reasons

Scalability / performance reasons

When teams should choose Artifact Registry

When teams should not choose it

4. Where is Artifact Registry used?

Industries

Team types

Workloads

Architectures

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) Central container image store for Compute-based apps

2) Kubernetes (OKE) cluster image source

3) CI pipeline push target for built images

4) Environment separation by compartment (dev/test/prod)

5) Third-party vendor image distribution inside OCI

6) Rollbacks with immutable image digests

7) Multi-team platform registry with standardized naming

8) Controlled distribution to air-gapped-ish subnets (egress-restricted)

9) Blue/green deployments that require fast, parallel pulls

10) “Golden base image” program

11) Disaster recovery preparedness for container artifacts

12) Migration from self-hosted registry to OCI-managed

6. Core Features

1) Managed repositories for container images

2) Standards-based push/pull with Docker-compatible tooling

3) Compartment-based organization

4) IAM policy-based access control

5) Tenancy namespace integration

6) Tagging and versioning conventions

7) API/Console/CLI manageability

8) Integration with OCI DevOps (common pattern)

9) Auditing via OCI Audit (control plane)

7. Architecture and How It Works

High-level architecture

Request/data/control flow (typical)

Integrations with related OCI services

Dependency services (conceptual)

Security/authentication model (common patterns)

Networking model (practical)

Monitoring/logging/governance considerations

Simple architecture diagram

Production-style architecture diagram

8. Prerequisites

Account/tenancy requirements

Permissions / IAM roles

Billing requirements

Tools needed

Region availability

Quotas/limits

Prerequisite services (for the lab)

9. Pricing / Cost

Pricing dimensions (model overview)

Free Tier (if applicable)

Primary cost drivers

Hidden or indirect costs

Network/data transfer implications

How to optimize cost (practical)

Example low-cost starter estimate (no fabricated prices)

Example production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Choose region, compartment, and find your registry namespace

Step 2: Create an Artifact Registry repository

Step 3: Create an auth token for Docker login

Step 4: Log in to Artifact Registry from your local machine

Step 5: Build a small Docker image locally

Step 6: Tag and push the image to Artifact Registry

Step 7: Create a small OCI Compute instance for validation

Step 8: Install Docker (or Podman) on the VM

Step 9: Log in from the VM and pull the image

Step 10: Run the container and validate it