Hello!

Wed, 09 Sep 2026 00:00:00 +0000

This is the first post on the new NXTRN development blog. As we are developing the NXTRN cloud platform we often run into interesting or unexpected problems that we need to design around and work through. We hope this blog will be a way for us to share those experiences with others and hopefully help the human collective not make those mistakes again. We love lofty goals here.

About NXTRN

NXTRN is a new cloud computing platform with strong opinions on how things should be done. At NXTRN we believe that many of our computing needs are solved problems already, we just need to apply the principles properly. For a straightforward example, think of a static HTML website. If you take a step back and abstract it enough, all you need is a DNS record and a properly provisioned web server. As a developer who needs a static site, you probably don’t care much about the web server being used to serve your files, the operating system running that web server, or even what IP address the web server has. A lot of times, a developer just wants to make a file available on the internet with minimal fuss and with a reasonable amount of safety.

That’s the premise of NXTRN. You declare how you need your infra and NXTRN meets those requirements.

The Spec

nickel

let SpecificationSchema = import "schemas/spec.ncl" in

let spec = {
  frontends = {
    www = {}
  },

  dns = {
    apex_domain = "example.com",
  },
} in

spec | SpecificationSchema

This is a nickel configuration file, which uses a (currently inaccessible) specification contract for validation. It establishes a DNS zone (example.com) and a single web frontend www. This tells the NXTRN platform that you want to create a static site and to make it available at www.example.com. Submitting a spec like this to the NXTRN platform would result in the provisioning of a tenant VM (if one does not yet exist) with 2 jails configured: a DNS server and a web server. These 2 jails + VM make up the premise of the NXTRN cloud platform. Infrastructure is written declaratively and implementation details like IP Addresses are abstracted away. Obviously there are IP addresses present, but they are managed by NXTRN along with other compute and storage resources. All your infrastructure is defined from this single file.

Nickel

NXTRN utilizes nickel for its configuration language. Inspired by HCL, we wanted a safe way to write infrastructure specifications in a declarative way, while also making it possible for developers to validate their specifications locally without requiring the NXTRN API. We wanted to support features such as loops and functions without accepting Turing-complete programs from our customers, so nickel seemed like a good fit.

The Platform

The NXTRN platform is built around Information Assurance principles:

Confidentiality
Integrity
Availability

We will dive into these principles in later blog posts, but here’s the quick version:

Confidentiality is a principle that your data should be safe from prying eyes, available only to the people or systems which require access to it. Integrity is the notion that the data you write should be the data you receive, without the ability for it to be modified at-rest or in-transit. And Availability is for making sure the data you have can actually be retrieved when needed, by the system that needs it.

The NXTRN platform has developed (and is actively developing!) architectures and opinions which adhere to these principles. Our goal is to build a system around these core principles while also making that platform easy to use and build on. NXTRN the company was built by former System Administrators, DevOps Engineers, System Architects, and System Engineers. We believe we can deliver a platform with strong guarantees while simultaneously making infrastructure easier to manage.

The Future