Installing Coder with Nuon

This is a first in a series of blog posts showing how software vendors' products can be configured and installed with Nuon. If you are a software vendor with an install base and want to be a candidate for a blog post, fill out the form and tell us more.

When I joined Nuon, I asked the team to build a Nuon App Config of my last company’s product, Coder, and use Nuon to install a few instances as if we are offering Bring Your Own Cloud (BYOC) of the Coder software to run in customers’ cloud accounts.

This example is about a developer-centric product called Coder but Nuon can deploy any application, from a vendor or internally-developed, in a customer's cloud - think any application, DevOps, security, AI - you name it.

What is Nuon and BYOC?

Nuon is a provider of enterprise software that enables the emerging Bring Your Own Cloud (BYOC) space to software vendors and customers who want the ease of instant access and upgrades with public SaaS but with the security and data sovereignty of self-hosted software. With Nuon, vendors more easily and cost effectively install and manage their software in customers’ cloud accounts with zero trust and limited access to the account while unlocking a new revenue stream for vendors.

What is Coder?

Coder is an open-source, self-hosted Cloud Development Environment (CDE) platform that provides enterprises with secure agentic and developer access to approved development environment configurations while improving developer productivity with instant onboarding - all within the confines of the customer’s cloud account or on-premises infrastructure. Coder offers a Premium edition to enterprises and government agencies with additional features like support, scalability, governance and security.

What Is Business as Usual with Self-Hosted Software?

Prospects evaluating and purchasing any self-hosted software rely on hiring talented DevOps and Dev Tools staff to learn, install and configure the self-hosted software to meet their stringent enterprise security and governance guidelines. Once installed and deployed into production, enterprise customers need to review new releases of the software in dev and test environments, before ultimately deploying into production for their end users. Security and data sovereignty requirements are met but without the SaaS experience of automatic upgrades.

For Both Vendors and Enterprises

Software vendors benefit from Nuon because it unlocks new revenue streams, either as single-tenant SaaS or BYOC installs in customers' clouds.

Vendors with a self-hosted only option today now can offer BYOC to existing customers or unlock new customers who do not have the skills to proceed with self-hosted.

Vendors with a SaaS-only option can unlock new customers with data sovereignty and security requirements.

Vendors with a home-built BYOC option can remove themselves from this complexity and cost with Nuon as their BYOC engine.

Enterprises can benefit from using Nuon as a customer of a vendor installing their software through Nuon in a BYOC fashion. Alternatively, enterprises can use Nuon to more easily deploy all of the vendor-purchased and internally-developed software.

Best of Both Worlds: A SaaS Experience Deployed In A Secure Customer’s Cloud

The rest of this blog post will outline in detail how a product like Coder, for example, can be setup as an App Config including the underlying infrastructure like Kubernetes, a Postgres database, creation of a Kubernetes secret for Postgres, the Coder control plane, a TLS certificate and an Application Load Balancer. With a couple clicks, a vendor can install Coder in any customer’s cloud account and watch the deployment in the Nuon Dashboard UI including detailed state and infrastructure logging available. The outcome is a publicly-accessible or VPC-managed Url for the customer and their developers to log into Coder and begin creating development environment templates and running cloud development environments.

Create the App Config

Check out the the repository which includes the Coder App Config and related TOML files for Nuon-specific configuration terminology.

Install Nuon CLI and Authenticate

You must request an organization before creating an App Config. If you are building you own App Config, please request access.

brew install nuonco/tap/nuon
nuon login

Inputs

Inputs are variables that the vendor manually enters when a customer's App Install commences. This example includes AWS and Coder specific Inputs. AWS Inputs include EC2 Instance Type and number of Kubernetes Nodes. Coder Inputs include environment variables that are fed into Coder’s values.yaml during the Helm deployment step such as Coder Release, Token and Session durations. The vendor has full control over what the Inputs should be.

Sandbox

Sandboxes are the underlying infrastructure that Coder is installed on, so in this case, an AWS EKS cluster. This Coder App Config uses a Nuon-managed AWS EKS Sandbox so there is little additional work required. Vendors can create their own Sandboxes as well.

Components

Components are the building blocks of the vendor’s application. So a simple, demo Coder App Config includes the following Components:

Certificate

There is a Certificate Component that uses Terraform to interact with AWS Certificate Manager to create an SSL/TLS certificate for secure connectivity from local IDEs and browsers to the Coder web dashboard.

Notice subject_alternative_names where we are using the same certificate for the wildcard subdmain and the domain_name for the base domain.

Terraform source is referenced in another directory in the App Config repo.

name              = "certificate"
type              = "terraform_module"
terraform_version = "1.11.3"

[public_repo]
repo      = "sharkymark/nuon"
directory = "src/app-config/coder/src/components/certificate"
branch    = "main"

[vars]
zone_id     = "{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.zone_id}}"
domain_name = "{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"
subject_alternative_names = "*.{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"

install_id  = "{{ .nuon.install.id }}"
region      = "{{ .nuon.install_stack.outputs.region }}"

# https://registry.terraform.io/modules/terraform-aws-modules/acm/aws/latest

Application Load Balancer

To provide user access to Coder control plane inside the EKS Kubernetes cluster, there is an ALB Component that uses Helm to deploy an Application Load Balancer with an HTTPS Listener and the Certificate.

Notice the domain_certificate references the AWS Manager’s certificate. By using other Component’s interpolated values, it passively designates a dependency on the Certificate Component, forcing the Certificate Component to be deployed first. Dependencies can be explicitly defined in the dependencies block like Coder Component.

name         = "application_load_balancer"
type         = "helm_chart"
chart_name   = "application-load-balancer"
dependencies = ["coder"]

[public_repo]
repo      = "sharkymark/nuon"
directory = "src/app-config/coder/src/components/alb"
branch    = "main"

[values]
domain_certificate = "{{.nuon.components.certificate.outputs.public_domain_certificate_arn}}"
domain             = "{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"

https_port         = "443"
service_name       = "coder"
service_port       = "80"
install_name       = "{{.nuon.install.id}}"
namespace          = "coder"
healthcheck_path   = "/livez"

Postgres

For demo purposes and simplicity, there is a Helm Component that deploys the Bitnami Postgres chart. We also have a Nuon Action that is triggered to create a base64 Kubernetes secret in the Coder namespace in the EKS cluster. The Coder control plane uses this secret to authenticate and communicate with Postgres. A future version of this Coder App Config will create and connect to an AWS RDS Postgres database but we wanted to reduce cloud costs and complexity for this demonstration.

Notice we only copied the Postgres helm chart into the App Config repository because the Bitnami repository is massive.

name           = "coder_db"
type           = "helm_chart"
chart_name     = "postgresql"
namespace      = "coder"
storage_driver = "configmap"

[public_repo]
# commenting out gitnami repo for now due to size
# https://github.com/bitnami/charts/tree/main/bitnami/postgresql
# that causes nuon build issues
# repo      = "bitnami/charts"
# directory = "bitnami/postgresql"
repo      = "sharkymark/nuon"
directory = "src/helm/postgresql"
branch    = "main"

[[values_file]]
contents = "./values/bitnami_postgres.yaml"

Coder control plane

There is another Helm Component that deploys Coder into the Coder namespace in the EKS cluster. The Component refers to a values.yaml with required and optional configurations like the Access Url, Wildcard Access Url, number of replicas and provisioner daemons, the Postgres secret, resource limits and requests for the Coder pod. Some environment variables in the values.yaml (called coder.yaml in the repo) are interpolated as Inputs provided during the initial Install step initiated by the vendor for its customer.

Below are snippets from the Coder values.yaml with interpolations for the Coder release, Access Url, Wildcard Access Url. Notice the empty secretNames array since we are terminating TLS at the ALB, and the Kubernetes secret that an Action created with the Postgres base64 credentials.

coder:

  image:
    # coder.image.repo -- The repository of the image.
    repo: "ghcr.io/coder/coder"
    tag: "{{.nuon.inputs.inputs.release}}"

  replicaCount: 1

  # since tls is terminated at alb
  tls:
    secretNames: []

...

  env:
    - name: CODER_PG_CONNECTION_URL
      valueFrom:
        secretKeyRef:
          name: coder-db-url
          key: url
    - name: CODER_ACCESS_URL
      value: "https://{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"
    - name: CODER_WILDCARD_ACCESS_URL
      value: "*.{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"

Actions

Actions are scripts that can be manually run from the Nuon dashboard or triggered by Components.

Default Storage Class

The AWS EKS Sandbox creates a Storage Class but does not mark it as Default. So before the Helm deployment of Postgres, an Action is triggered to designate the gp2 Storage Class as Default. This is required for Persistent Volume Claims to be created, both for Postgres and eventually developers' Coder workspaces if the Kubernetes template is used.

Postgres Secret

As mentioned in the Postgres Component, the Coder control plane expects a Kubernetes secret with the Postgres credentials.

Post Deployment Health Checks

After Helm deploys Coder and the Application Load Balancer, a Health check Action is triggered to output the health of the pods and service in the Coder namespace and curl the ALB endpoint. The outputs are viewable in the Nuon dashboard logs.

App Config Conclusions

A vendor will have several different App Configs. For example, a separate App Config for each Cloud, because the Sandboxes will be different per cloud provider. There could a simple, demo App Config like the one in this blog post, but also a production App Config that has an external RDS Postgres database. What’s important is the vendor can easily reuse these App Configs to create new App Configs leveraging their previous work.

Install the App in a Customer’s Cloud Account

Once an App Config is defined, the vendor would use the Nuon dashboard to kick off an Install on behalf of a customer. In Nuon, a customer Install's progress is tracked in a Workflow, a list of Steps to provision and log the Customer’s Install of the App Config.

Inputs

The vendor populates Inputs in the Nuon dashboard such as AWS EC2 Instance type and size, number of nodes, Coder Release, and Coder environment variables.

Once Inputs are collected, the Workflow creates a link to an AWS CloudFormation stack which is shared with the customer to run in their AWS account.

Inputs such as secrets can be entered or pulled from AWS Secrets Manager by the customer when creating the CloudFormation stack. The vendor has no knowledge or access to these secrets. Nuon has a sync feature where if configured, will synchronize those secrets into a Kubernetes namespace.

Provision an EC2 VM with the Nuon Runner

The CloudFormation stack creates an EC2 VM with Docker and Runner container. The Runner phones home to the Nuon control plane to receive additional steps to provision the App Config.

The stack’s template includes permissions defined in the App Config for Provision, Maintenance, and De-provision IAM Roles, which the customer’s AWS account authorizes the Runner to perform. Provision and De-provision Roles have elevated permissions to do things like create and destroy EKS clusters. In this example, the Maintenance permissions are elevated to let a Nuon Action create the Postgres secret.

Provision the Sandbox

The Sandbox is the underlying infrastructure, e.g., the AWS EKS cluster.

Depending on the Cloud provider, this is a time consuming step of creating a Node pool, Nodes, and the EKS cluster. e.g., 20-30 minutes and is a function of the cloud provider, not Nuon.

Deploy the Components

Deploy the Actions

Open Coder in a browser

Create A Coder Workspace

Conclusions

With Nuon, vendors can quickly provision multiple Installs of their Apps for customers. As new releases of their App come up, vendors can easily upgrade these customer Installs. This flexibility and speed can empower vendors to unlock new revenue streams where prospects would prefer to run vendors' Apps in their cloud accounts but with the ease of installation, maintenance and upgrades performed by the vendors and powered by Nuon. Enterprises benefit either as the recipient of vendors' BYOC option with Nuon, or alternatively can deploy Nuon internally to more easily and cost-effectively manage their inventory of internally-developed or vendors' self-hosted software.

If this excites you and your enterprise is in need of a BYOC deployment option, please tell us more in the Demo request or sign up for the Trial.