A registry your pipeline already knows how to use
No proprietary CLI, no custom manifest format — the documented workflow is plain Docker.
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
From the docsThe registry-secret flow, as documented for E2E Managed Kubernetes:
# 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-secretHow it works
Registry to running pod in four steps.
Set up the registry
One-time setup from MyAccount › Container Registry (or the setup API), then create projects for each team or service.
Mint tokens
Issue a token per consumer — your laptop, CI runner, each cluster. Refresh or revoke independently as pipelines change.
Push & scan
docker push from CI, trigger a vulnerability scan on the artifact, and check findings via API before promoting the tag.
Deploy everywhere
Kubernetes pulls via imagePullSecrets; TIR runs the image as a custom container; replication keeps secondary registries in sync.
Standards & capabilities
Everything below is verifiable in E2E's public documentation and API reference.
| Capability | Status | Detail |
|---|---|---|
| Registry endpoint | Documented | registry.e2enetworks.net — per the E2E Kubernetes registry-secrets guide |
| Docker toolchain | Documented | docker login / push / pull; digest-addressed images (@sha256:…) |
| Kubernetes integration | Documented | docker-registry secrets + imagePullSecrets |
| TIR integration | Documented | Container registry is part of TIR's storage surface for custom containers |
| Projects & repositories | Documented | Project-scoped repos, artifact listings, project logs |
| Access tokens | Documented | Create / refresh / update / revoke via API |
| Vulnerability scanning | Documented | Artifact, repository and project-level scans; vulnerabilities endpoint |
| Replication | Documented | Source registries with ping check; policies + execution tracking |
| Toolchain compatibility | Documented | docker push/pull, sha256-digest image refs, Kubernetes imagePullSecrets |
| Pricing | On rate card | Billed in INR* — see pricing |
*Indicative — see the live rate card for current pricing.
Frequently Asked Questions
Everything you need to know about Container Registry.
Container Registry
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.
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.
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.
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.
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.
Ship images at data-center speed
Set up your private registry in minutes — no sales call required.