Hiphops container registry
Hiphops container registry is the easiest way to store and share Docker images. Images can be shared privately with self-hosted customers in a couple of minutes.
Private but shareable
Hiphops registries are designed for sharing non-public images.
You can grant access to anyone or no-one, to specific images or everything, internal users or external, machine access or human.
Built-in auth system. Create users, configure their level of access and the resources they should have access to, in addition to minting JWTs for those users.
Revokable, long lived tokens. Give external access without having to rotate tokens - whilst still being able to revoke issued JWTs in future. Expiring tokens are fine too.
⚡️ Coming soon ⚡️
Share existing registries. Configure an existing registry such as ECR as a pull through cache. This allows you to use Hiphops access control to share images, without changing where you push.
Push to customer cloud Add connections to your registry, allowing you to seamlessly deliver your images into a customer’s own cloud account.
Zero setup
Hiphops registries are created automatically on project creation, with no additional steps.
Every project in Hiphops has exactly one container registry, hosted on a project specific subdomain of the form YOUR_SUBDOMAIN.ctr.dev
Ready to go? Follow the quickstart
Integrate easily
If your product relies on shipping container images to customers, managing access manually quickly becomes unscaleable.
Dashboard or API. Manage your registry via the dashboard or automate via the REST API as part of your customer onboarding flow.
Interactive API reference docs. Docs are great, interactive docs that let you test drive the API before you write code are even better. Take a look at the API reference docs
OCI spec compliant
Your registry on ctr.dev meets the OCI distribution spec, in addition to compatibility with popular container tools.
Hiphops also offers additional management endpoints beyond the OCI spec (such as viewing storage usage, deleting images). Additional endpoints are always documented via our API Reference doc.