Cloud Documentation

Reference Architectures

The rest of our documentation covers individual features - how to create a VM, how a VPC works, how volumes are snapshotted. Reference architectures put those pieces together into a complete, working deployment, and explain the decisions behind it: which offering to pick, which way to publish a server to the internet, which ports to open and why.

Every architecture is documented four ways - a portal walkthrough, the equivalent CloudMonkey commands, an Ansible playbook and a Terraform configuration - so you can start by clicking through it once and end up deploying it repeatably from code.

Available architectures

  • RA-01. Basic VM - single cPanel server

    The simplest deployment: one VM on an isolated network with a dedicated public IP, published by static NAT with a firewall rule set for web, mail and control panel traffic. The example workload is cPanel/WHM on AlmaLinux 9, but the pattern suits any single-server workload.

More on the way. We're building these out as we go - multi-tier VPC, load-balanced web tier, and Kubernetes patterns are next. If there's a deployment pattern you'd like documented, let us know and we'll prioritise it.

How to use these

Each architecture follows the same structure:

  • Architecture - a diagram of what you end up with, and how traffic flows through it.
  • Resource plan - every zone, offering, template and disk size in one table, so you can price it and check it against your account's resource limits before you start.
  • Design decisions - the choices that aren't obvious, with the reasoning and the trade-offs, so you can deviate deliberately rather than by accident.
  • Portal walkthrough - the click-by-click build, in order.
  • Automation - CloudMonkey, Ansible and Terraform equivalents of the same build.
  • Verify - checks to confirm the deployment actually works before you put load on it.
  • Day 2 - what to snapshot, how to scale it, and what not to change.

Names, CIDRs and admin IP ranges in the examples are placeholders - substitute your own. Everything else (zone names, network offerings, compute offerings, template names) is real and can be used as-is on Lightspeed Cloud.

Before you start

The automation examples authenticate with an API key and secret key rather than your portal password - see API access for how to generate a pair. For diagramming your own variation of an architecture, the design aides include the same icon set used in the diagrams on these pages.