---
title: "Private Container Registry in India — Docker Push, Pull & Scan"
description: "Private Docker container registry in Indian data centers: registry.e2enetworks.net. Push and pull with the standard Docker toolchain, scan images for vulnerabilities, replicate across registries, and wire into Kubernetes with imagePullSecrets and TIR custom containers."
url: "https://www.e2enetworks.com/container-registry"
canonical: "https://www.e2enetworks.com/container-registry"
provider: "E2E Networks Limited"
type: "Service"
keywords: ["private container registry india", "docker registry cloud india", "container image registry kubernetes india", "private docker registry with vulnerability scanning"]
priceCurrency: "INR"
taxNote: "Prices exclude GST"
region: "India (Delhi NCR, Chennai)"
generated: "2026-09-11"
---

# Private Container Registry in India — Docker Push, Pull & Scan

> Private Docker container registry in Indian data centers: registry.e2enetworks.net. Push and pull with the standard Docker toolchain, scan images for vulnerabilities, replicate across registries, and wire into Kubernetes with imagePullSecrets and TIR custom containers.

Canonical page: https://www.e2enetworks.com/container-registry

Your images, your registry, your data center. A private container registry at registry.e2enetworks.net — standard Docker push and pull, project-scoped access tokens, vulnerability scanning and replication. Sitting next to your Kubernetes clusters and TIR workloads, so pulls stay inside the data center.

## At a glance

- **Docker/OCI** — Standard toolchain
- **Scanning** — Artifact, repo & project level
- **Tokens** — Revocable, per-pipeline
- **🇮🇳** — Images stay in India

## Platform capabilities

- **Standard push & pull** — docker login registry.e2enetworks.net, then push and pull by tag or immutable sha256 digest — the exact references E2E's own Kubernetes docs use. Anything speaking the Docker/OCI registry protocol works.
- **Projects & repositories** — Organise images into project-scoped repositories with per-project details, artifact listings and audit logs — team boundaries that map to how you actually ship.
- **Token-based access control** — Create, refresh, update and revoke registry tokens via the API. Give CI, clusters and teammates separate credentials — and kill any of them without a password reset party.
- **Vulnerability scanning** — Trigger scans per artifact, per repository or across a whole project, then read findings from the vulnerabilities endpoint. Gate your deploys on real data.
- **Replication** — Register remote source registries (with a ping connectivity check), define replication policies, and track executions — mirror images into India or sync environments automatically.
- **Full REST API** — Registry setup, projects, tokens, scans and replication are all first-class operations in the MyAccount API — the whole registry is scriptable and Terraform-able.

## From laptop to cluster without leaving India

Build locally or in CI, push to your private registry, and let Kubernetes pull over the local network with an imagePullSecrets reference. The same images back TIR custom containers for notebooks, training jobs and inference endpoints — one registry feeding the whole AI stack — with datasets on Object Storage and PFS, and stateful disks on Block Storage, all in the same data center.

## Wire it into Kubernetes

The registry-secret flow, as documented for E2E Managed Kubernetes:

```bash
# Create a Docker registry secret (docs.e2enetworks.com)
kubectl create secret docker-registry my-registry-secret \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-server=registry.e2enetworks.net

# Reference it from the pod spec
spec:
  containers:
  - name: app
    image: registry.e2enetworks.net/your-repo/your-image@sha256:<digest>
  imagePullSecrets:
  - name: my-registry-secret
```

## How it works

1. **Set up the registry** — One-time setup from MyAccount › Container Registry (or the setup API), then create projects for each team or service.
2. **Mint tokens** — Issue a token per consumer — your laptop, CI runner, each cluster. Refresh or revoke independently as pipelines change.
3. **Push & scan** — docker push from CI, trigger a vulnerability scan on the artifact, and check findings via API before promoting the tag.
4. **Deploy everywhere** — Kubernetes pulls via imagePullSecrets; TIR runs the image as a custom container; replication keeps secondary registries in sync.

## Registry capabilities

| Capability | Documented | Detail |
| --- | --- | --- |
| Registry endpoint | Yes | registry.e2enetworks.net — per the E2E Kubernetes registry-secrets guide |
| Docker toolchain | Yes | docker login / push / pull; digest-addressed images (@sha256:…) |
| Kubernetes integration | Yes | docker-registry secrets + imagePullSecrets |
| TIR integration | Yes | Container registry is part of TIR's storage surface for custom containers |
| Projects & repositories | Yes | Project-scoped repos, artifact listings, project logs |
| Access tokens | Yes | Create / refresh / update / revoke via API |
| Vulnerability scanning | Yes | Artifact, repository and project-level scans; vulnerabilities endpoint |
| Replication | Yes | Source registries with ping check; policies + execution tracking |
| Toolchain compatibility | Yes | docker push/pull, sha256-digest image refs, Kubernetes imagePullSecrets |
| Pricing | No | Billed in INR* — see pricing |

## Frequently asked questions

### Do I need an E2E-specific CLI or plugin?

No. The documented workflow is the standard Docker one — docker login registry.e2enetworks.net, docker push, docker pull, digests and tags. Your existing CI images and build scripts carry over unchanged, and they'd carry out again just as easily: that's the standards-based deal.

### Why host images in India instead of Docker Hub?

Three practical reasons: pulls from your E2E Kubernetes and GPU nodes stay inside the data center (fast cold starts for large AI images), you're not subject to public-registry rate limits, and images with proprietary models or code stay under Indian jurisdiction.

### How should I structure access for a team?

One project per service or team, a repository per image, and a token per consumer. CI gets a token that can push; clusters get tokens that only pull; every token is individually revocable via the API. Registry activity is visible in project logs.

### Can I mirror my existing registry into E2E?

Yes — register your current registry as a source (the API includes a ping check to validate connectivity), then create a replication policy. Executions are tracked via the API so you can monitor sync status. This is the usual first step in a gradual migration.

### How does this feed AI workloads specifically?

TIR's custom containers pull from the registry, so the same image serves as your training environment, your notebook base and your inference endpoint runtime. Multi-GB CUDA images pull at data-center speed instead of over the internet — which you'll feel every time a node pool scales up.

## Get started

Set up your private registry in minutes — no sales call required. Pricing: https://www.e2enetworks.com/pricing · Talk to sales: https://www.e2enetworks.com/contact-sales

- [Start Free](https://myaccount.e2enetworks.com/accounts/signup)
- [Talk to an Engineer](https://www.e2enetworks.com/contact-sales)

---

This Markdown is generated from the same data that renders https://www.e2enetworks.com/container-registry. Provider: E2E Networks Limited (NSE: E2E), India. Site index for AI agents: https://www.e2enetworks.com/llms.txt