You package an app for Nuon by creating an app config. This is where you will define what environment the app needs, what components it consists of, and how it will be configured during deployment.

​
Inputs

Inputs are how your app will be configured during deployment.

​
Integrating with the Customer Environment

Because the customer will be hosting your app in their environment, you may want to include security and cost management options. A few example of options you might include are:

  • Integrate with their own auth provider, such as Auth0.
  • Configure what VPC to deploy in for security reasons.
  • Configure what size VM instance to use, to manage cost.

​
Grouping

To keep things managable, we recommend grouping inputs by domain. For example:

  • App Preferences: admin user, admin password, and other app settings
  • VPC Configuration: VPC ID, Private Subnet ID, Public Subnet ID
  • Hosting Options: Instance Type, Use Auto-Scaling

​
Secrets

If your customer needs to configure passwords, private tokens, or other sensitive values, define an input as a secret. Secret values are saved to the target platform’s secret store in the customer’s account, and are never stored or accessed by the Nuon control plane.

​
App Configuration

While you can use inputs for your app’s own internal configuration and preferences — such as setting an admin password or connecting to a customer database — we recommend against this if possible. Allowing your customer to update settings like this within your app will likely provide a better experience.

​
Sandbox

The sandbox is where you define the environment your app will run in, and therefore acts as part of the contract you are making with your customer regarding access and security. This is where you will make foundational decisions about the network resources will be deployed to, so it pays to be thoughtful about what your app’s requirements are.

We provide off-the-shelf sandboxes to get you started quickly. See the Sandboxes page to learn how to use these. A sandbox is just a Terraform module, though, so you can also create a custom sandbox to meet more specialized needs.

Regardless of which sandbox you use, we recommend pinning to a specific version, and upgrading carefully to avoid disrupting your customer’s experience of your app.

​
Isolated vs Customer-Managed Networks

The most important consideration for the sandbox is whether your app will run in it’s own, isolated network, or be deployed into a customer-provided network. If the latter, you will need to provide inputs to configure what network to deploy in, and other options that will depend on the cloud platform you are deploying to.

​
Network Configuration

If you have the option of defining the network your app will be deployed in, there are some best practices we recommend. Even if the customer is managing the network, you may want to discuss these with them to ensure you are being set up for success.

Be thoughtful about what subnets you define and how you use them. In most cases, we recommend having 3 types:

  • Private Subnets: This is where you should put most of your resources by default.
  • Public Subnets: These should only be used for internet-facing resources, like public load balancers.
  • Database Subnets: If your app includes any database, isolating them in their own subnet is a common best practice.

Before making a load balancer internet-facing, consider whether it needs to be. Your customer may prefer keeping the app private to the network it’s deployed in, and can access it using a VPN.

If your app does require internet-facing components, consider putting a WAF in place to provide an extra layer of monitoring and protection.

​
Components

Components are how you model your app’s architecture in Nuon. How you configure these will define how your app is deployed and updated.

​
Dependencies

Components typically have dependencies on each other. In the app config you can use outputs from one component as inputs to another to integrate them. Ensure you define components in the correct order, so a component’s dependencies are in place before it is deployed.

Even if components are deployed in the correct order, dependencies may still fail. Certain cloud resources may not be ready for use, even if they have been created successfully. When testing your app, look for potential race conditions that may require retries or other mitigations.

​
Networking and DNS

You will typically need to manage DNS with your components to host your application at a private or public URL. Customers often want to see apps hosted at a subdomain under a domain they own, which will require integrating with a DNS zone that they manage.

​
Databases and Other Stateful Components

Stateful components can be challenging to manage with infra-as-code. This is especially true of databases, as they tend to be costly, operationally complex, and involve the risk of data loss.

Beyond just defining a component for resources like these, you may want to use actions to implement things like schema migrations and configuration updates.