Nebari Deployment Behind Corporate Firewall: Custom Docker Image Registry Configuration

[millsks]

I’m evaluating the Nebari platform to consolidate several services we currently run separately. I was able to deploy it locally on my personal Mac, but I’m now testing on a Mac behind a corporate firewall on a private network.

My goal is to use the same Docker images but override the default image repositories to pull from our internal repo, which acts as a proxy for Docker Hub and Quay.io.

I noticed there’s an open PR addressing an upstream change in Bitnami image locations. While that PR fixes things internally for Nebari, is there a way to configure this behavior in nebari-config.yaml so that images are always pulled from a custom/internal repo instead?

This is primarily for local deployment now, but we’re also exploring deploying on Kubernetes infrastructure hosted on OCP.

[viniciusdc]

Hey @millsks — thanks for checking out Nebari!

I’m evaluating the Nebari platform to consolidate several services we currently run separately. I was able to deploy it locally on my personal Mac, but I’m now testing on a Mac behind a corporate firewall on a private network.

Great to hear you got a local deployment running. On your question about using a custom container registry: Nebari doesn’t yet have a global registry setting that applies across all components. While Nebari supports overrides for many deployed resources, there isn’t a single “set the registry for everything” knob today.

For now, the way to achieve this is to add per-component overrides in your nebari-config.yaml (similar to the PR you referenced). Because many Nebari components are installed via upstream Helm charts, we try not to change image versions/registries globally. Here’s an example override for one component:

security:
  keycloak:
    initial_root_password: <redacted>
    overrides:
      postgresql:
        image:
          registry: docker.io
          repository: bitnamilegacy/postgresql
          tag: "10"

As an alternative (cluster-wide and manifest-agnostic), you can configure your cluster nodes to use a registry mirror/pull-through cache. With containerd/CRI-O you can map docker.io to an internal mirror so pulls are transparently redirected—no manifest edits required.

Another option: deploy Kyverno (e.g., via Helm) and add a policy that rewrites any external image registry (like docker.io) to your internal registry. This lets you enforce/override registries without touching Nebari manifests. Just keep in mind your internal registry must host or mirror all the required images and tags used by Nebari’s components for this to work smoothly.

[millsks]

@viniciusdc are you aware of anyone that has successfully got Nebari deployed locally using Podman? Anyone deployed to OCP?

I am able to get the deployment started with Podman, but one of the biggest issues that I am seeing with using Podman/kind is the networking differences.

I can open issues for this, but it was more just discussion right now. We will eventually be looking at getting it deployed to OCP, but we wanted to do a show and tell first which would be better suited locally.

[viniciusdc]

Hey @millsks, as far as I can remember, I think @tylerpotts was able to get something around podman recently; besides that, I don't know.

[tylerpotts]

Hi @millsks, I think @viniciusdc is referring to the time I deployed Nebari locally with Rancher on Mac. Networking was also the challenge there. I had to setup several manual port forwards with kubectl in order to allow the python process running Nebari to access the relevant pods.

As for OCP, I haven't seen Nebari deployed on that specifically yet. Nebari is capable of deploying on any existing Kubernetes clusters so your use case is supported. Docs for that can be found here

[millsks]

Thanks @tylerpotts

I had to something similar with Podman to get ports forwarded. Our corporate network also causing us problems due to other restrictions. I think I'll hold off on the local deployment and just look into OCP deployment.

Thank you both for your input.