Skip to main content
When you purchase NexusOne, you choose the deployment model you want to use to install NexusOne into your Kubernetes cluster. Whichever model you choose, the installation comes down to the same steps:
  1. You write a configuration file and pass it to the shared_service_deployer.py script. Refer to Deploy NexusOne for details.
  2. A Kubernetes job runs the nx1-deployer image.
  3. The image runs Terraform.
  4. Terraform installs a set of NexusOne Helm charts bundled inside the nx1-deployer image.
  5. NexusOne organizes every component into tiers, such as core, modules, and tenant. Those charts deploy NexusOne components, like Airflow, into the core and modules tiers of your cluster.
The tenant tier doesn’t deploy as part of this run. It’s a separate, on-demand request. You ask Tenant Manager, a component in the modules tier, to create one, and it runs its own Terraform job just for that tenant, into its own namespace.

​
Deployment models

The following table describes the four supported deployment models. In summary, here’s who each model suits:
  • Self-hosted: Suits teams that already have their own CI/CD pipeline and want deployment to be one more step in it.
  • Nexus Cognitive hosted and operated: Suits teams that want NexusOne fully managed, with Nexus owning the cluster too. You only interact with the applications.
  • Nexus Cognitive operated: Suits teams that would rather not manage the cluster at all and hand the keys to Nexus, but still want it running on their own infrastructure.
  • Client self-service: Sits in between. You keep full control of your cluster, but you’re using tooling Nexus built and maintains, rather than building your own.
Whichever model you pick, the result is identical. It’s the same image, the same Terraform, the same charts.

​
Additional resources

For more information about what that Kubernetes job actually installs, refer to Deployment architecture.