[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"modules":3},{"modules":4,"trialIncludesAll":63},[5,17,28,39,51],{"key":6,"name":7,"summary":8,"description":9,"highlights":10,"monthlyPrice":16},"virtualization","Virtualization","Sell VMs off your own Proxmox fabric, with private networks.","Attach your Proxmox servers and let customers order, boot and console into VMs themselves. Allocation is billed alongside power and traffic on the same monthly report, and tenant VXLAN overlays ride on the same fabric.",[11,12,13,14,15],"Proxmox servers, VM lifecycle and templates","Self-service provisioning with per-VM sanity caps","Browser console (noVNC) without handing out hypervisor logins","vCPU \u002F memory \u002F disk billed per month at your rates","Private networks: per-tenant VXLAN overlays",39,{"key":18,"name":19,"summary":20,"description":21,"highlights":22,"monthlyPrice":27},"routing","Routing","See the VRRP and FRR state your hosts are actually running.","Discovery parses keepalived and FRR configuration off your hosts and turns it into a view of failover groups, peers and advertised prefixes, so the routing layer is documented by the machines rather than by a wiki page nobody updated.",[23,24,25,26],"keepalived \u002F VRRP instances, priorities and state","FRR peers and advertised prefixes","A mesh view of who talks to whom","Parsed on discovery, so it cannot go stale",19,{"key":29,"name":30,"summary":31,"description":32,"highlights":33,"monthlyPrice":38},"bookkeeping","Bookkeeping","Turn the monthly usage report into draft invoices in lexoffice.","Push a closed month straight into your own lexoffice account as draft invoices, one per customer, with the energy, bandwidth and flat lines already filled in. You still review and issue them; nothing is sent without you.",[34,35,36,37],"Draft invoices per tenant from the usage report","Your tax type and rate, including EU reverse charge","Invoices raised in your own lexoffice account","Nothing issued automatically; you approve every one",15,{"key":40,"name":41,"summary":42,"description":43,"highlights":44,"monthlyPrice":50},"deployment","Deployment","Reinstall a machine over the network, from the rack list.","Arm a server against a boot image and power-cycle it: the site agent hands it the loader over PXE and streams the kernel and initrd from its own disk, so a reinstall runs at LAN speed and does not depend on your uplink. A machine nobody armed is offered no boot file at all and comes up on its local disk as usual.",[45,46,47,48,49],"Legacy BIOS, UEFI and UEFI HTTP boot from one arming","Images cached at the site: reinstall without the WAN","One-shot by default, so a box installs once and not on every reboot","Checksum-pinned images, refused if the bytes do not match","Progress reported back per machine: armed, served, booted",25,{"key":52,"name":53,"summary":54,"description":55,"highlights":56,"monthlyPrice":62},"rdns","Reverse DNS","Let customers set the PTR on their own addresses, without a ticket.","Point DCIM at the nameservers that already answer for your address space: Technitium over its HTTP API, or BIND (and anything else speaking RFC 2136) over a TSIG-signed dynamic update. Reverse DNS then becomes a field on the address, editable from the server, the IP plan or the VM, and a customer can name their own machines without opening a ticket for a one-line change.",[57,58,59,60,61],"Technitium and BIND \u002F RFC 2136, IPv4 and IPv6","Edit the PTR from the device, the IP plan or the VM","Customers set reverse DNS on their own addresses only","Credentials stay encrypted here; nobody gets a nameserver login","Every change audited, with the nameserver's own reason on failure",12,true]