PLATFORM
An unbelievable deal. Same suite that runs the lights.
A gateway you run is the core: agents dial out, you sign the rules, every handshake is ML-DSA-65. Around that: Galaxy, Nexus, Alien Queue, VPN, antivirus, identity and equity. The lights business pays for it.
- Starter $0
- Pro $10 / domain
- Nexus transit free
- ML-DSA-65
- You run the gateway
Alien Lights Development Platform
Alien Lights makes lighting, and that is what we primarily sell. The development platform is what we built to run it, and you can run your own things on it: post-quantum identity, secure remote access, a message queue, signed firmware and packages, and a private VPN. One suite, one price.
See pricingSign up nowOverview
No military. No spying. No corporate espionage. No copying other companies' patented products. No suppressing activists. Read the terms.
Pricing in one minute
Starter
$0 / month
Your company, every feature, at you@company.alienlights.net
- All of the platform below, with Starter limits
- Two users included, then $10 a month each. Unlimited devices
- No storage charge, because we do not store your data
Pro
$10 / month, per domain you bring
Two users included, then $10 each. Galaxy Direct at Cloudflare's published rate (at cost)
- Everything in Starter, on a domain you already own
- Users: 2 included, then $10 a month each. Devices stay unlimited
- Galaxy Direct: you pay for all transit, at Cloudflare's published rate (at cost). No included amount
- Nexus transit is free. No base fee
Full pricing, tables and examples
The gateway and the Alien VPN exit run on machines you own, so you pay for that hardware and network yourself. The pricing page says how users, domains, and transit are billed. Galaxy Direct has no included amount.
Before you try Alien VPN
Your corporation must run its own gateway to connect to anything other than Auto connect. Auto connect is the default: it shows which Cloudflare edge you reach and how it is performing, and it carries nothing. The full device tunnel carries all of a phone's traffic, and it only connects through a gateway and exit that your own corporation operates. Alien Lights does not operate an exit.
Everything in the platform
Zero Trust Access
Gateway, agent and signed rules Available
Replaces a corporate VPN or Cloudflare Zero Trust for the services you expose. A gateway you deploy, an agent that only dials out, and rules you sign. Every handshake is authenticated with ML-DSA-65.
- Customer-deployed gateway; rules verified on your side
- Devices open no inbound port
- Revoke a person or device and live tunnels close
Galaxy Remote Access
SSH and remote desktop Available
Reach servers and desktops through post-quantum tunnels. Every connection is its own tunnel, checked against your rules.
- SSH from the command line and in the app
- RDP for Windows, Screen Sharing and VNC for macOS and Linux
- Agents for Windows, macOS and Linux from one source
Alien VPN
Auto connect and the full device tunnel In development
Auto connect shows the Cloudflare edge you reach, live on a map of 308 data centers, and needs nothing from you. The full device tunnel sends all of a phone's traffic through an exit your corporation runs.
- Exit:
alienlights-ztna agent run --vpn-exit(builds from source until the next package release), no root and no firewall changes - IPv4, IPv6 and DNS through one post-quantum tunnel; blocked, not leaked, if it drops
- Your corporation must run its own gateway to connect to anything other than Auto connect
Alien Queue and Alien Poke
Sealed messages your devices keep Queue available
Alien Queue is a post-quantum publish and subscribe log that stores ciphertext it cannot read. Alien Poke uses it for short signed nudges between people in your organisation.
- Encrypted on the producer with a key only your organisation holds
- Partitions, consumer groups and replay
- Pokes are signed by their sender and expire after 7 days
Nexus
Signed firmware and packages Available
Run the gateway with --nexus and it keeps your signed firmware and packages on your own machine, named by SHA-256. Devices fetch from it, authenticated with post-quantum identities.
- Bytes that do not match their name are refused
- Your nodes serve your fleet; those bytes are not billed
- apt and yum repositories, signed
System on a Chip
Raspberry Pi, Jetson, BeagleBone Available
Boards that run Linux are managed like any computer, through apt or dnf, with signed commands and metrics only your company can read.
- amd64, arm64 and armhf packages
- Remote package management
- Post-quantum device identity
PlatformIO firmware signing
ESP32, STM32 and RP2040 Available
Every build is measured, hashed and signed, with one line in platformio.ini. Size budgets keep CI honest.
- ML-DSA-65 signed firmware
- Size budgets that are safe in CI
- Each device image carries its own ML-DSA-65 identity
Factory
Fleet-scale provisioning Separate project
One secure root that makes a whole fleet post-quantum: a scale-out k3s cluster on Raspberry Pis that writes firmware with unique identities.
- Up to 40 microcontrollers per Pi
- Hardened images per supported SoC
- A Nexus node per host
Alien Antivirus
Signed definitions, scans on the device Scanner available
Signed malware definitions you verify on the device, an APK and firmware scanner, and a honeypot that ties malicious update attempts to botnet intel.
- Scans on the device and uploads nothing
- In the gateway and the suite packages
- The on-phone app is in development
Starlink IoT
Remote sites behind carrier NAT Connectivity available
The agent only dials out, so a pump station or fleet vehicle on Starlink has nothing to forward and nothing to open. It reconnects after outages.
- Telemetry interval you set
- Same post-quantum identity
- Dish telemetry is planned
Identity and OAuth
Free sign-up, no card Available
Use your existing OAuth or OpenID Connect provider, or ours for free. Tokens are signed with Ed25519 and ML-DSA-65, with a transparency log and client-held keys.
- Merkle transparency log
- Client-held keys
- Works with the rest of the suite
Relay only Available
Post-quantum mail. We route it and we do not store it. Your phone is the mailbox.
- Relay-only, post-quantum mail
- Production and development company addresses
- Sealed to the phone
Where each part stands
We say what works and what does not. Available means it runs today and we have tested it. In development means it is written and tested in pieces but not shipped. The full device tunnel still needs a gateway and exit your corporation runs. The detailed status table is on the overview.
Start
- Read the pricing, then sign up. Your company address is free. Two users are included, then $10 a month each. A domain you bring is $10 a month.
- Install the gateway and agent from the package repositories and follow Set it up.
- Sign your rules, then reach your devices with
alienlights-ztna ssh,desktopandvpn check.
Making WLED devices or IoT lighting? That is our vertical and it pays for the platform. Start at Build the Future, or see Alien Lights.
One suite. Post-quantum from the device to the cloud.
The platform is zero trust access, device management, mail, a message queue and identity, built on one post-quantum identity layer. Your company owns its data end to end and holds the keys. We make it post-quantum and carry it across Cloudflare's global network. Production mail is free at you@company.alienlights.net. Development mail is free at you@company.dev.alienlights.net. A domain you bring is $10 a month through Stripe, on either. Two users are included, then $10 a month each. Galaxy Direct is the over-the-internet path. Nexus transit is free. alienlights.net is the root.
Making WLED devices or IoT lighting? That is our vertical and it pays for the platform. Start at Build the Future. See the field of use.
Zero Trust Access
Available
Replaces Cloudflare Zero Trust with a gateway you run, a device agent that dials out, and rule sets you sign. Every handshake is authenticated with ML-DSA-65.
- Customer-deployed gateway
- Rules synced from our API, verified on yours
- Sits behind free Cloudflare Tunnel
System on a Chip
Available
Raspberry Pi, Jetson, BeagleBone and other Linux SoCs, managed through apt and yum packages. Remote package management with signed commands.
- Post-quantum device identity
- Metrics only your company can read
- amd64, arm64 and armhf
Microcontrollers
Available signing · Available post-quantum identity
ESP32, STM32 and RP2040 boards go through PlatformIO. Every build is measured, hashed and signed.
- ML-DSA-65 signed firmware
- Size budgets, CI-safe
- One line in platformio.ini
Factory
Separate project tested on Raspberry Pi 4B
One secure root that makes the whole fleet post-quantum. A scale-out k3s cluster on Raspberry Pis that writes firmware with unique identities, up to 40 microcontrollers per Pi.
- Hardened images per supported SoC
- A Nexus node per host, any Helm chart
- Works with any PlatformIO project
Alien Antivirus
Available scanner · Available honeypot · Planned phone app
Signed malware definitions you check on the device, an APK and firmware scanner, and a honeypot that catches malicious update attempts and ties them to botnet intel.
- Scans on the device, uploads nothing
- In the gateway, SOC and suite packages
- A young feed that grows with the network
Security Operations
Available
For the people who run a security operations center: CLI, zero trust tools and a threat intel feed you can pipe into your SIEM.
- Threat intel sync timer
- JSON records to syslog
- Decrypts your fleet's metrics locally
Alien Queue
Available
A post-quantum publish/subscribe message queue, a stand-in for Kafka in your own systems. Only your company and its devices can read it.
- Encrypted on the producer
- Partitions, consumer groups, replay
- Key rotation when members leave
Your Data
Available transit · Available Nexus node · Planned bucket transit
Your corporation owns its data end to end. It lives in your own cloud or on your own nodes. We carry it post-quantum, authenticated by device and user identity.
- We do not store your data
- No storage charge
- Over Cloudflare's global network
Starlink IoT
Available connectivity · Planned dish telemetry
Remote sites on Starlink sit behind carrier-grade NAT. Our agent dials out, so there is nothing to forward and nothing to open.
- Reconnects after outages
- Telemetry interval you set
- Same post-quantum identity
Identity & OAuth
Available
Hook into your existing OAuth or OpenID Connect provider, or use ours for free. Tokens are signed with Ed25519 and ML-DSA-65.
- Free sign-up, no card
- Merkle transparency log
- Client-held keys
Equity
Available
One ring per Corp, included free. You see your own stake. Corp admins see that Corp's book, and Alien Lights admins are root.
- Included, no extra charge
- One ring per Corp
- A signed PDF to buy, and one for work
Also in the suite
Galaxy remote accessNexus syncThreat intelligenceOpen firmware securityIdentityEquity
Where each part stands
| Part | Status |
|---|---|
| Zero trust gateway, device agent, client, signed rules | Available |
| Remote package management (apt, dnf) | Available |
| Sealed device metrics and access logs | Available |
| Alien Queue | Available |
| apt and yum repositories, signed | Available |
| PlatformIO firmware signing | Available |
| Any TCP service, including a self-hosted S3-compatible store, carried by identity | Available |
| Native transit for cloud buckets (S3, R2, GCS) with device and user identity | Planned |
Gateway runs as a Nexus node with --nexus: signed firmware and package cache on your own machine, in the apt and yum packages | Available |
| A Nexus node per host on a k3s cluster, installed with Helm (Factory) | Separate project |
| Factory: hardened images per SoC, unique post-quantum identities, up to 40 microcontrollers per Pi | Separate project |
| Alien Antivirus scanner, signed definitions and honeypot, in the gateway package | Available |
| Alien Antivirus as an on-device Android app | Planned |
| Alien Antivirus scanning of installed Android apps | Planned |
| Starlink dish telemetry as a metrics source | Planned |
| SSH to devices through the tunnel, from the command line | Available |
| Remote desktop through the tunnel: RDP for Windows, Screen Sharing or VNC for macOS, VNC for Linux (your viewer, our tunnel) | Available |
Alien VPN exit: a machine you run (agent run --vpn-exit) that carries a device's whole traffic, with vpn check to test it | Builds from source, next package release |
| Alien VPN full device tunnel on Android (needs your own gateway and exit; Auto connect needs neither) | In development |
| Agent for Windows and macOS (remote access and commands) | Builds from source, no installer yet |
| Built-in RDP and VNC viewer inside the app | Planned |
| Flutter app with 3D connection map | In development |
| Managed edge hostname with Cloudflare DDoS and bot mitigation (Pro) | Planned |
| Post-quantum identity written into microcontroller firmware (Factory) | Separate project |
| Factory-issued microcontroller identities connected to this gateway, with sealed metrics | Planned |
| Equity, one ring per Corp, included free | Available |
Zero Trust Access Available
Alien Zero Trust replaces a corporate VPN or Cloudflare Zero Trust for the services you expose: SSH, databases, internal tools. There are three parts. A gateway that you deploy. An agent on each device that dials out, so the device opens no inbound port. A client your people run. Policy is a rule set you sign. The gateway syncs it from our API and checks the signatures before it applies a single rule.
Post-quantum handshake
Gateway, device and user prove who they are with ML-DSA-65 signatures over the handshake transcript. A proxy that terminates TLS in the middle cannot pretend to be any of them. If the gateway terminates TLS itself it also negotiates the X25519MLKEM768 hybrid key exchange.
Rules that we cannot forge
Your organisation's owner signs the rule set. Alien Lights countersigns it. The gateway verifies both. Our API can deliver a rule set. It cannot write one.
Customer-deployed gateway
One static binary on your own host. It holds a token, not your keys. If our API is unreachable the gateway keeps enforcing the last verified rules.
Revocation takes effect now
When a rule changes or an identity is revoked, the gateway rechecks tunnels that are already open and cuts the ones that are no longer allowed.
Sealed access logs
Access events are encrypted to your organisation's ML-KEM-768 and X25519 key before they leave the gateway. We hold only ciphertext, for at most 30 days. You read them with alienlights-ztna metrics.
Signed commands
Commands to a device, such as listing or upgrading packages, are signed by the person who sent them. The gateway and the device each verify the signature.
Run the gateway as a Nexus node
Post-quantum transit is Nexus plus nodes that you host, and it is one flag on the gateway: alienlights-ztna gateway run --nexus. The same process that enforces your rules now also keeps your signed firmware and packages on your own machine, named by SHA-256. Your devices fetch from it. Every request is signed with the caller's ML-DSA-65 identity and checked against your signed rule set: your owner identity writes, enrolled devices read. Bytes that do not match their name are refused, and bytes your node serves are Nexus transit, which is free. The over-the-internet path is Galaxy Direct: post-quantum zero trust and over-the-air binary flash, billed at Cloudflare's published rate (at cost). See how it fits the pricing.
It is a cache of signed artifacts, not a place for secrets. Relaying Nexus device sync through your own nodes, and devices finding the nearest node on their own, are planned.
Cloudflare in front, free
The gateway needs one public hostname. Put it behind a Cloudflare Tunnel and Cloudflare's network, DNS and DDoS absorption sit in front of it. A tunnel config template is installed with the package at /usr/share/doc/alienlights-ztna/gateway-cloudflare-tunnel.yml.example.
Pro is meant to add a managed hostname with Cloudflare DDoS and bot mitigation in front of it. That managed hostname is not built yet. Today you set the tunnel up in your own Cloudflare account.
Set it up
Install alienlights-ztna from the apt or yum repository, then:
# owner, once
alienlights-ztna enroll --name "owner"
alienlights-ztna org create --name "Acme" # prints a gateway token, keeps org.json (your decryption key)
alienlights-ztna rules init > policy.json # edit it, then:
alienlights-ztna rules publish policy.json
# gateway host
sudo alienlights-ztna enroll --dir /var/lib/alienlights-ztna/gateway --name "gw-1"
echo '{"listen":":8443","token":"zt_..."}' | sudo tee /var/lib/alienlights-ztna/gateway/gateway.json
sudo systemctl enable --now alienlights-gateway
# device
sudo alienlights-ztna enroll --dir /var/lib/alienlights-ztna/agent --name "$(hostname)"
sudo systemctl enable --now alienlights-agent
alienlights-ztna devices # what you may reach
alienlights-ztna ssh pi@DEVICE # SSH through the tunnel (name or id)
alienlights-ztna desktop DEVICE --protocol rdp # Windows Remote Desktop on a loopback port
alienlights-ztna desktop DEVICE --protocol vnc # macOS Screen Sharing or a Linux VNC server
alienlights-ztna exec DEVICE pkg.list
alienlights-ztna metrics # decrypted on your machine
Keep org.json safe. It holds the key that decrypts your metrics and logs. Alien Lights cannot recover it.
SSH and remote desktop for Windows, macOS and Linux Available
The device owner turns on what a machine offers. The people allowed to use it are named in your signed rules. Every connection is its own tunnel, authenticated with ML-DSA-65 on both ends, so a proxy in the middle cannot pose as the gateway or the person.
# on the device (Windows, macOS or Linux)
alienlights-ztna agent run --ssh # OpenSSH on 127.0.0.1:22
alienlights-ztna agent run --rdp # Windows Remote Desktop on 127.0.0.1:3389
alienlights-ztna agent run --vnc # macOS Screen Sharing or a Linux VNC server on 127.0.0.1:5900
alienlights-ztna agent run --service db=127.0.0.1:5432 # any other TCP service
# in your rules: who may open which service on which device
{"effect":"allow","principals":["group:ops"],"devices":["tag:lab"],"actions":["tunnel:ssh","tunnel:rdp"]}
SSH
alienlights-ztna ssh user@device runs your normal OpenSSH through the tunnel, so your own keys, agent and host-key checks still apply. Nothing listens on the internet, and port 22 can stay closed to everyone.
Remote desktop
alienlights-ztna desktop device opens a loopback-only port and starts your viewer: mstsc on Windows, Microsoft Remote Desktop or Screen Sharing on macOS, FreeRDP, Remmina or a VNC viewer on Linux. We carry the bytes. We do not replace the viewer.
The agent builds for Windows, macOS and Linux from the same source. On Windows and macOS it offers remote access and signed commands. Package management and the metrics report are Linux features for now. Remote desktop uses the viewer on your own computer.
Alien VPN: the full device tunnel Exit builds from source Android app in development
Auto connect and the full device tunnel are the two modes of Alien VPN. Auto connect needs nothing from you: it shows the Cloudflare edge you reach and how it is performing, and it does not carry your traffic anywhere. The full device tunnel sends every packet the phone sends, IPv4, IPv6 and DNS, through one post-quantum tunnel to an exit your corporation runs, so websites see your exit's address and your private network is reachable as if you were in the office.
Your corporation must run its own gateway to connect to anything other than Auto connect. Alien Lights does not operate an exit for the full device tunnel. Without a gateway of your own there is nothing for it to connect to.
# on a machine in your network: this is the exit (no root, no TUN device, no firewall changes)
# build from source for now: cd ztna && go build ./cmd/alienlights-ztna
alienlights-ztna agent run --vpn-exit
alienlights-ztna agent run --vpn-exit --vpn-dns 10.0.0.2:53 --vpn-deny 10.99.0.0/16
# in your rules: who may use the exit
{"effect":"allow","principals":["group:staff"],"devices":["tag:exit"],"actions":["tunnel:vpn"]}
# check it from your laptop: tunnel, DNS and a TCP connection, all through the exit
alienlights-ztna vpn check office-exit
The same post-quantum tunnel
The device tunnel is a Galaxy tunnel to the service vpn, so it is authenticated with ML-DSA-65 on both ends, checked against your signed rules, and cut off when a person or device is revoked. Packets are carried inside it; the gateway cannot read them any more than it can read SSH.
An exit with nothing to install
The exit ends the phone's packets in a userspace network stack and opens ordinary sockets from the machine it runs on. It needs no root. It always refuses loopback, link-local (including cloud metadata addresses), multicast and anything you list with --vpn-deny. DNS from the phone goes to the resolver you choose, so private names resolve.
On the phone
The phone starts an Android VPN service after Android's own consent dialog, and Android shows its key icon while it runs. If the tunnel drops, traffic is blocked until it is back; it does not fall through to the open network.
Honest limits. The --vpn-exit flag and vpn check are in the source tree and ship in the next package release; the published 0.4.0 packages do not have them yet. Android only for now: Windows, macOS and Linux have vpn check but no system-wide tunnel yet. Ping (ICMP) is not carried. It carries TCP and UDP. The exit is a general internet exit for the people your rules name, so run it where you would run any corporate egress, and keep the prohibited uses in mind. The exit is tested end to end through a gateway. The Android part is compiled and its logic is tested, but we have not run it on a phone yet.
The 3D connection map In development
We are building a Flutter app that draws your gateways, devices and live tunnels as a 3D force-directed graph. It reuses the 3D graph engine behind our live infrastructure page, so you can see that visualization working today on public data. The app is not released yet. Until it is, alienlights-ztna devices lists what you can reach.
What it does not do
Alien Zero Trust carries TCP services between an authenticated person and an authenticated device, and, through an exit you run, a phone's whole traffic. It does not filter DNS or HTTP, and it does not isolate browsers. If you rely on those parts of Cloudflare Zero Trust, keep them.
System on a Chip Available
A Raspberry Pi, a Jetson, a BeagleBone or any other Linux board is a computer. So it is managed like one, through apt or dnf. Install a package, enrol the device, and your company can reach it and manage its packages. Boards that cannot run Linux go through PlatformIO instead, on the Microcontrollers tab.
A post-quantum identity on the device
Enrolling creates an ML-DSA-65 key pair on the device. The private key never leaves it. Anyone who wants to reach the device, or tell it to do something, has to prove their own identity the same way.
Remote package management
Your people can list, upgrade and install packages on a device from alienlights-ztna exec. A command has to be signed by the person who sent it, allowed by your signed rules, and allowed by the device's own policy.
The device has the last word
The default local policy allows pkg.list, pkg.upgrade, and pkg.install of alienlights-* packages. pkg.remove is off. Nothing we or you send can widen that. Only someone with access to the device can.
Metrics only your company can read
The agent reports hostname, OS, kernel, architecture, uptime, load, memory, disk, temperature and the number of pending package updates. It seals the report to your organisation's key on the device. It passes through our API sealed and waits up to 30 days for you to collect it. We cannot read it. You decrypt it with alienlights-ztna metrics and your own key.
Bring a device under management
sudo apt install alienlights-soc
sudo alienlights-ztna enroll --dir /var/lib/alienlights-ztna/agent --name "$(hostname)"
sudo tee /var/lib/alienlights-ztna/agent/agent.json <<'J'
{"gateway_url":"https://gw.example.com","gateway_id":"GATEWAY-UUID",
"services":{"ssh":"127.0.0.1:22"}}
J
sudo systemctl enable --now alienlights-agent
Add the device's UUID to devices in your policy and publish it. Then, from your own machine:
alienlights-ztna exec DEVICE pkg.list
alienlights-ztna exec DEVICE pkg.upgrade
alienlights-ztna metrics
The packages
Signed packages for Debian and Ubuntu (apt) and for RHEL, Fedora, Rocky and Alma (dnf or yum), built for amd64, arm64 and armhf.
| Package | What it puts on the machine |
|---|---|
alienlights-suite | The whole suite in one install: security operations, system on a chip, firmware tools and the queue CLI. |
alienlights-soc | System on a chip: the device agent and the CLI. |
alienlights-secops | Security operations center: CLI, zero trust gateway and user tools, and the threat intel feed. |
alienlights-ztna | The alienlights-ztna binary with systemd units for the gateway and the agent. Built for amd64, arm64 and armhf. Nothing starts until you enrol an identity. |
alienlights-factory | The factory machine package. Add an API key from the admin settings with alienlights-factory set-key and it registers itself. Needs Node.js 20.19 or newer. |
alienlights-gateway | The zero trust gateway. Same one-step setup with alienlights-gateway set-key. |
alienlights-mq | The alienlights-mq command for Alien Queue. Built for amd64, arm64 and armhf. |
alienlights-cli | The alienlights command: service status, free sign-up, identity lookup, OAuth/OIDC checking, doctor. |
alienlights-intel | A systemd timer that pulls the public threat feeds to /var/lib/alienlights/intel. Does nothing until you enable it. |
alienlights-firmware | The PlatformIO plugin, pq_identity.mjs and docs under /usr/share/alienlights/platformio/. |
Debian and Ubuntu
curl -fsSL https://alienlights.net/alienlights-repo.asc \
| sudo gpg --dearmor -o /usr/share/keyrings/alienlights.gpg
echo "deb [signed-by=/usr/share/keyrings/alienlights.gpg] https://alienlights.net/packages/apt stable main" \
| sudo tee /etc/apt/sources.list.d/alienlights.list
sudo apt update
sudo apt install alienlights-soc
RHEL, Fedora, Rocky, Alma
sudo curl -fsSL -o /etc/yum.repos.d/alienlights.repo https://alienlights.net/packages/alienlights.repo
sudo dnf install alienlights-soc # or: sudo yum install alienlights-soc
Two ways to manage a device
| System on a chip | Microcontroller | |
|---|---|---|
| Boards | Raspberry Pi, Jetson, BeagleBone, i.MX | ESP32, STM32, RP2040 |
| Runs Linux | Yes | No |
| You manage it with | apt or dnf | PlatformIO |
| Device identity | ML-DSA-65, post-quantum Available | ML-DSA-65 Available |
| Remote package management | Available | Not applicable. Firmware is updated by signed image. |
| Metrics sealed to your key | Available | Planned |
Verify what you install
The apt repository is signed (InRelease), the yum metadata is signed (repomd.xml.asc) and every RPM carries its own signature. One key signs all of it. Check the fingerprint against this page before you trust it:
curl -fsSL https://alienlights.net/alienlights-repo.asc | gpg --show-keys --with-fingerprint
# Alien Lights Packages <packages@alienlights.net>
# B462 2542 77D8 7044 920F 9D03 4206 3C53 9773 C1E1
Microcontrollers: signed firmware with PlatformIO
Secure firmware should not be a release-day chore. The PlatformIO plugin hooks into pio run, so every build of every board is measured, stamped, hashed and signed the same way, from the first prototype to the production image. It is one Python file and one line in platformio.ini.
Stamps every build
Defines ALIEN_FW_VERSION, ALIEN_GIT_SHA (with -dirty when the tree has local changes), ALIEN_BOARD and ALIEN_BUILD_SIGNED, so a device can report exactly what it is running.
Signs the image
Writes a detached ML-DSA-65 signature over the SHA-512 of the binary, plus a .sha512 file in sha512sum format. Set custom_alien_artifacts to sign more than one output.
Writes a manifest
A firmware.bin.manifest.json with version, board, git revision, size, SHA-256, SHA-512, the signature and the signing key's fingerprint.
Enforces a size budget
custom_alien_max_bytes = auto (the default) reads the board upload.maximum_size. Set an exact number to override. The build fails with the exact overage.
Verifies and publishes
pio run -t alien_verify re-checks the signature. pio run -t alien_publish copies .bin, .sig, .sha512 and the manifest to custom_alien_publish_dir (or ALIEN_PUBLISH_DIR), then runs ALIEN_PUBLISH_CMD if set.
Safe for CI
With custom_alien_require_signing = yes a build with no key fails instead of shipping unsigned. custom_alien_require_clean = yes refuses a dirty git tree. Locally, no key means a clearly labelled unsigned dev build.
Add it to a project
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
extra_scripts = post:/usr/share/alienlights/platformio/alienlights.py
custom_alien_version = 0.15.1
custom_alien_max_bytes = auto
custom_alien_require_signing = yes
custom_alien_require_clean = yes
custom_alien_publish_dir = dist/firmware
Build and sign
export ALIEN_SIGNING_KEY=~/keys/firmware-signing.key
pio run -e esp32dev
pio run -e esp32dev -t alien_verify
pio run -e esp32dev -t alien_publish
Key: a 32-byte ML-DSA-65 seed. The private key is never written into the image. With a key set, the plugin also writes the ML-DSA-65 public key for on-device verification.
What a build prints
Output of a real build for an ESP32 with the Arduino framework.
Building .pio/build/esp32dev/firmware.bin
Successfully created ESP32 image.
alien: firmware.bin 291632 bytes sha256 1b0cb7d5cf4e74c8
alien: signed ml-dsa-65 key 7d9e053168ab7f94
alien: size budget 291632 / 1900544 bytes (15.3%)
========================= [SUCCESS] Took 66.16 seconds =========================
.pio/build/esp32dev/
firmware.bin the image you flash
firmware.bin.sig 3309-byte ml-dsa-65 signature
firmware.bin.sha512 sha512sum-format hash
firmware.bin.manifest.json version, board, git, size, hashes, key fingerprint
Know what is running
void setup() {
Serial.begin(115200);
Serial.printf("fw %s (%s) built from %s signed=%d\n",
ALIEN_FW_VERSION, ALIEN_BOARD, ALIEN_GIT_SHA, ALIEN_BUILD_SIGNED);
}
When something goes wrong, it stops
alien: ERROR: firmware is 15960 bytes, over the custom_alien_max_bytes budget of 10000 (over by 5960)
alien: ERROR: custom_alien_require_signing is on but no signing key is set (export ALIEN_SIGNING_KEY=/path/to/key.pem)
alien: ERROR: signature does NOT match program
The signature format is the one the Alien Lights OTA flow already uses: firmware.bin, firmware.bin.sig and firmware.bin.sha512, verified on the device against the embedded public key before anything is flashed. The plugin works with any PlatformIO board or framework that produces a binary; for other output files, such as .hex or .uf2, point custom_alien_artifact or custom_alien_artifacts at the files. The package ships pq_identity.mjs and @noble/post-quantum next to the plugin so identity minting works offline. It is included in Starter and Pro alike, and signing never touches the network.
Source: tools/platformio/alienlights.py · install path: /usr/share/alienlights/platformio/
Post-quantum identity and secure updates
The PlatformIO plugin above gives every build a signature you can check, and a post-quantum identity of its own. It mints an ML-DSA-65 key, writes the public key and a device id into alien_pq_identity.h, and records them in the manifest. The seed stays in .alien/device-identity.json on the machine that built the image. Set custom_alien_embed_pq_seed = yes only for a one-device image you flash yourself and do not publish: that copy of the seed is then inside the binary. Available
Two separate projects go further. The Factory writes firmware with a unique post-quantum identity for any PlatformIO project, and does it for up to 40 boards at a time from one Raspberry Pi. See the Factory tab. A separate WLED project handles secure over-the-air updates for WLED, so a malicious binary pushed to a device is refused. Separate project
What is not built here yet: connecting Factory-issued identities to this gateway so microcontrollers report sealed metrics the way Linux devices do. Planned A board running Linux should use the System on a Chip path instead.
Factory: one secure root, a post-quantum fleet Separate project
The Factory is where a fleet gets its identity. It is a scale-out k3s cluster built for Raspberry Pi, provisioned with Ansible, that writes firmware with a unique post-quantum identity for each device and works with any PlatformIO project. Start a fleet here and every device has a post-quantum identity from its first boot. It is a separate project from the packages on this page. It was tested on the Raspberry Pi 4B.
Scale-out k3s on Raspberry Pi
Ansible turns Raspberry Pis into a k3s cluster. Add another Pi and the cluster, and the number of boards you can program, grows.
Hardened images per SoC
Hardened images are published for each supported system on a chip, so a host starts from a known, signed image and not from a general-purpose one.
Up to 40 microcontrollers per Pi
A SaberNet 10x USB expansion on each Raspberry Pi lets one host write up to 40 microcontrollers. Tested with the Raspberry Pi 4B.
Unique post-quantum identities
Every device is written with its own identity, not a shared key. Revoking one device does not touch the others.
A Nexus node per host
The cluster boots from Helm charts that run a Nexus node on every host. Your data is cached on your own machines.
Any Helm chart
It is a normal k3s. Install any Helm chart you like next to the Nexus nodes.
The chain of trust
Security here comes from where the chain starts. The Factory is the root. Everything below it is only as trustworthy as the first link.
- Start at the root. One secure Factory holds the signing keys and makes the images and the firmware.
- Sign what it makes. Hardened SoC images and microcontroller binaries are signed. Each device is given its own post-quantum identity.
- Accept only what is signed. A device takes an update only if it is signed by the root. This is the job of the WLED project for WLED over-the-air updates, and of the signed builds from the PlatformIO plugin.
- Recognise each other by identity. Devices, hosts and people prove who they are with post-quantum signatures, in the gateway and in Alien Queue.
- Watch the edge. Alien Antivirus checks images, runs a honeypot for attackers and links what it catches to botnet intelligence.
Start from the root, or reflash
A device that began life with unsigned firmware cannot prove anything about itself, so the chain cannot be added to it from outside. There are two ways to be inside the chain:
| New fleet | Existing fleet |
|---|---|
| Build it from the Factory. Every host and board has a signed image and its own identity from the start. | Reflash every product with the Factory's signed images and your own signed binaries. Until a device is reflashed it is outside the chain. |
What this does not promise
We do not call this invincible, because nothing is. A fleet that starts at the root has no way to be updated with an unsigned binary, which closes the malicious over-the-air update path. These are still yours to handle:
| Covered by the chain | Not covered by the chain |
|---|---|
| Unsigned or tampered firmware over the air | Theft of the root signing keys. Keep them offline and guard them. |
| A device pretending to be another device | Physical attack on a device, such as reading flash. That depends on the chip's secure boot and flash encryption. |
| Eavesdropping on keys and sessions with a future quantum computer | Bugs in your own application code, and in the open-source code you build on |
| Devices left on unsigned firmware, once they are reflashed | Denial of service. A device can be knocked offline even if it cannot be taken over. |
The Factory is described here from its author's own testing on the Raspberry Pi 4B. It is not shipped in the apt and yum packages, and the images and charts are not published on this site yet.
Alien Antivirus Available
Alien Antivirus checks files against definitions we sign, on your machine. It scans Android apps and firmware images, and it can run a honeypot that looks like the unauthenticated update page on WLED and similar firmware, so attackers show their hand. It is part of the gateway package, so it is on every System on a Chip, Security Operations and suite install.
Definitions you can check
The feed is a malware graph of families, actors and indicators. It is signed with ML-DSA-65 and Ed25519, and the device checks both signatures before it uses it. A device refuses older definitions than the ones it has.
Calculated on the device
The device builds its own lookup table from the graph, keyed by SHA-256, so a check is one hash and one lookup. Each node also gets a fixed spot in a 3D force map from its hash, so every device draws the same map. The position is for drawing. It plays no part in detection.
Nothing is uploaded
Scanning happens on the device and no file leaves it. There is no endpoint to submit a file. Reporting is opt-in and sends only the SHA-256, the signing certificate hash and the package name of a flagged app, signed by your device identity. A hash is added to the shared definitions only after at least three different devices report it.
Android apps
It reads an APK's manifest, signing certificate and code strings without running the app, and matches them against the feed. It lists risky capabilities, with MITRE mobile technique hints, such as an accessibility service that draws over other apps. These describe what an app can do. Real SMS and accessibility apps trip them, so they rank apps for a closer look and are not verdicts.
Firmware images
It recognises ESP32 and ESP8266 images and ELF files, looks inside them for addresses and domains, and matches them against the botnet feed. fwcheck verifies an image's detached signature, the same ML-DSA-65 signature the PlatformIO plugin writes.
A honeypot for microcontroller attacks
The decoy answers like WLED's update page, takes the "firmware", and records who sent what. It never runs, forwards or fetches anything it is sent. Payloads are kept as inert files only you can read. The addresses it finds are matched to the botnet campaigns in our threat intel, and events can be sealed to your organisation's key.
Install and run it
sudo apt install alienlights-ztna # also in alienlights-soc, -secops and -suite
alienlights-av update # fetch the signed definitions and verify both signatures
alienlights-av info
alienlights-av scan ~/Downloads # exits 1 on a detection
alienlights-av scan --adb # third-party apps on a phone connected with adb
alienlights-av fwcheck app.bin --key fleet.pub.pem
sudo systemctl enable --now alienlights-av-update.timer
sudo systemctl enable --now alienlights-honeypot.service # the decoy
"No match" means the definitions do not know the file. It does not mean the file is safe.
How it fits with secure updates
Alien Antivirus does not make a device refuse a bad update. That is the signed firmware path: the Factory, the PlatformIO plugin and the WLED project, which accept only signed binaries. Alien Antivirus is the other half: it catches attackers who try, shows where they came from, and links them to botnet operations. Devices that were not started from the Factory's root need reflashing before they can refuse an unsigned update.
Where each part stands
| Part | Status |
|---|---|
| Signed definitions, on-device index, signature and downgrade checks | Available |
| APK scanner and capability scoring, firmware scanner, signature check | Available |
| Honeypot with sealed events, in the gateway, SoC, secops and suite packages | Available |
| Phone scanning from a computer with adb | Available |
| An Android app that scans on the phone | Planned |
| Alien Antivirus scanning of installed Android apps | Planned |
| Checking Factory post-quantum firmware signatures | Planned |
| Honeypot sightings feeding the shared botnet intel | Planned |
| A 3D map viewer for the definitions graph | Planned |
Included in every plan. There is no separate price.
Security Operations Available
For the analysts and engineers who run a security operations center. Install alienlights-secops on an analyst or SIEM host and you get the CLI, the zero trust gateway and user tools, and the threat intel feed.
Threat intel sync
A systemd timer pulls the public botnet campaign, attack chain and APT catalog feeds to /var/lib/alienlights/intel. It runs as a throwaway systemd user with a read-only filesystem and no capabilities.
Straight into your SIEM
Set syslog = yes and every sync writes one compact JSON object per campaign and attack chain to the journal, with a kind of botnet_campaign or attack_chain. Point Filebeat, Vector, Splunk UF or rsyslog at the tag.
Your fleet, decrypted on your machine
Device metrics and access events arrive sealed to your organisation's key. alienlights-ztna metrics decrypts them locally. Alien Lights never has the key.
Your identity provider
alienlights oauth check reads your provider's discovery document the way an application would, and tells you what is wrong before you wire anything to it.
The first five minutes
sudo apt install alienlights-secops # or: sudo dnf install alienlights-secops
alienlights doctor # checks the install and the hosted services
alienlights signup --name "secops-01" # free identity, saved to ~/.config/alienlights/identity.json (mode 600)
sudo systemctl enable --now alienlights-intel.timer # hourly threat intel sync
alienlights intel show # campaigns and attack chains from the last sync
journalctl -t alienlights-intel -o json # the same records, for your forwarder
Feeds are read from public endpoints and nothing is uploaded from your machine. Add the repository first, from the System on a Chip tab.
SOC here means security operations center. This is a toolkit for the people who run one. It is not a SOC 2 report and it is not an audited product, and the packages say so in their README.
Alien Queue Available
A publish/subscribe message queue built on the same ideas as mail: sealed, signed, and unreadable to the service that carries it. Topics are split into partitions. Consumers in a group share a committed offset and can replay from the start. A device or a service produces. Another consumes. It is a relay for your traffic and not an archive: the service holds ciphertext only for the retention you set, up to 30 days. Keep your own copy in your own storage.
Encrypted on the producer
Each record is sealed with AES-256-GCM under a topic key that we never receive. The key is handed to each member sealed to their ML-KEM-768 and X25519 key, and signed by the organisation owner.
Signed by the producer
Inside the ciphertext every record carries an ML-DSA-65 signature from the identity that produced it. A consumer checks it. A compromised service cannot put words in a device's mouth.
Only your members can use it
The topic's producers and consumers are listed in a configuration the owner signs. The service refuses anyone who is not on it, and a consumer refuses a configuration the owner did not sign.
Leaving means a new key
Remove a member and the topic moves to a new key epoch. The person who left cannot read anything written afterwards. They keep what they could already read, which is true of any encrypted system.
Partitions, groups, replay
Up to 64 partitions per topic, retention up to 30 days, long-poll consumers, per-group offsets you commit yourself, and replay from any offset still retained.
Carried by Cloudflare's network
Producers and consumers enter Cloudflare's network at the location nearest them, and each partition runs as a Cloudflare Durable Object. There is no storage charge. See pricing.
Try it
sudo apt install alienlights-mq # or: sudo dnf install alienlights-mq
alienlights-ztna enroll --name "producer-01" # an identity, once per machine
alienlights-mq init --org org_... --owner OWNER-UUID
# the owner creates the topic and grants its key to the members
alienlights-mq topic create telemetry --partitions 2 --retention 24h \
--producers PRODUCER-UUID --consumers CONSUMER-UUID
alienlights-mq produce telemetry --key sensor-1 "temp=61.5" "temp=62.0"
alienlights-mq consume telemetry --group dashboards --commit --follow
A person who is not on the topic gets "topic not found". A consumer that tries to produce is refused before anything is sent.
What we can and cannot see
| Alien Lights can see | Alien Lights cannot see |
|---|---|
| Topic names and partition counts | Message contents |
| Which identity produced a record | Message keys |
| Record sizes and times | The topic encryption key |
| Which identities are on a topic | What a consumer committed to, beyond an offset number |
Compared with Kafka
Alien Queue is a stand-in for the way you use Kafka, not a drop-in for its protocol. Kafka clients and Kafka Connect cannot talk to it today. You use alienlights-mq or the Go package behind it. Ordering is per partition, and records with the same key land in the same partition within one key epoch. A key rotation can send the same key to a different partition afterwards.
Limits today: 100 topics per organisation, 256 members per topic, 100 records or 1 MB per produce call, 256 KB per record.
Your Data Available
Your corporation owns its data, end to end. We do not store it, so we do not bill for storing it. It lives where you put it: in your own cloud provider, on your own servers, or cached on your own nodes. What the platform does is the transit. We make the movement of that data post-quantum, tie every transfer to a device identity and a user identity, and carry it across Cloudflare's global network.
Stored by you
Your cloud provider's buckets, or machines you run. You choose the provider, the region and the retention. You pay them for storage. We never see an invoice line for it.
Cached on Nexus nodes Available
Signed firmware and packages your fleet uses often can sit close to your devices on your own machines. Start the gateway with --nexus and it is a Nexus node: see how. Bytes that node serves are Nexus transit, and Nexus transit is free. On the Factory's k3s cluster there is a Nexus node per host, installed from Helm charts Separate project.
Moved post-quantum
Both ends prove who they are with ML-DSA-65 signatures. Sealed payloads use ML-KEM-768 and X25519 with AES-256-GCM. Neither end has to trust the network, a proxy or us.
Tied to a device and a user
A transfer is allowed only when the device is on your signed rules and the person is too. Revoke either identity and open connections are cut.
Galaxy Direct, over the internet
Galaxy Direct is post-quantum zero trust network access over the internet, including over-the-air binary flash. Traffic enters and leaves at the Cloudflare location nearest each side. You pay Cloudflare's published rate (at cost) on all of it. There is no included amount. Nexus transit is free. See pricing.
Relays hold ciphertext briefly
Alien Queue and sealed metrics pass through our service as ciphertext and wait for you to collect them, for at most 30 days. They are buffers. They are not where your data lives.
What works today
The zero trust gateway carries any TCP service between an authenticated person and an authenticated device. Point a service at a self-hosted S3-compatible store such as MinIO or Ceph and your people reach it by identity, with nothing exposed to the internet:
{"gateway_url":"https://gw.example.com","gateway_id":"GATEWAY-UUID",
"services":{"ssh":"127.0.0.1:22","objects":"127.0.0.1:9000"}}
alienlights-ztna connect DEVICE objects --listen 127.0.0.1:19000
# then point any S3 client at http://127.0.0.1:19000
What is not built yet
| Part | Status |
|---|---|
| Native transit for buckets in your cloud provider (S3, R2, GCS), signed by device and user | Planned |
Gateway as a Nexus node (--nexus) inside the apt and yum packages | Available |
| Archiving an Alien Queue topic into your own bucket | Planned |
Starlink IoT Available
A pump station, a weather mast or a fleet vehicle on Starlink is a hard place to run a VPN. Standard Starlink service commonly sits behind carrier-grade NAT, so you cannot forward a port to the device, and the link comes and goes. Alien Zero Trust was built for this. The device agent only ever dials out, so there is nothing to forward and nothing to open.
Nothing inbound
The agent opens one outbound connection to your gateway. Remote access, package commands and metrics all travel over it. No public IP, no port forward, no relay you do not control.
Reconnects by itself
When the dish loses sky or the link drops, the agent reconnects with jittered backoff of up to a minute. It does not need a person on site.
You choose the data rate
Set telemetry_interval_seconds in agent.json. The default is every 5 minutes. On a metered plan, every 15 minutes cuts the metrics traffic to a third.
Same identity everywhere
A device on Starlink has the same ML-DSA-65 identity as one on a wired network, and your rules apply to it the same way. Its metrics are sealed to your key.
Set up a remote site
sudo apt install alienlights-soc
sudo alienlights-ztna enroll --dir /var/lib/alienlights-ztna/agent --name "pump-station-7"
sudo tee /var/lib/alienlights-ztna/agent/agent.json <<'J'
{"gateway_url":"https://gw.example.com","gateway_id":"GATEWAY-UUID",
"telemetry_interval_seconds":900,
"services":{"ssh":"127.0.0.1:22"}}
J
sudo systemctl enable --now alienlights-agent
A Raspberry Pi, Jetson or other Linux board on the dish's network does the job. Boards that cannot run Linux sit behind it and are programmed through PlatformIO.
What is not built yet
| Part | Status |
|---|---|
| Outbound-only agent, reconnect, configurable telemetry | Available |
| Starlink dish telemetry (signal, obstructions, data usage) as a sealed metrics source | Planned |
| Starlink Direct to Cell and other satellite IoT radios | Planned |
| Store-and-forward of metrics while a site is offline | Planned |
Alien Lights is not affiliated with or endorsed by Starlink or SpaceX, and Starlink is their trademark. We have not yet tested the agent on Starlink hardware. It works the same way on any link that allows outbound connections.
Bring your own OAuth, or use ours for free
You should not have to move your users to adopt a security suite. The suite works with the OAuth and OpenID Connect provider you already run, and if you do not run one, Alien Lights is a free one.
Hook into yours
Okta, Entra ID, Google, Keycloak, anything that speaks OpenID Connect
alienlights oauth check --issuer URLreads the provider's discovery document the way an application would and tells you what is wrong before you wire anything to it: issuer mismatch, endpoints that are not https, missing PKCE, a JWKS with no keys.- Set
issuerinalienlights.confonce andalienlights doctorchecks it every time. - An Alien Lights identity can link any standards-compliant OAuth2 or OIDC provider an operator has configured.
alienlights oauth providersshows which are ready andalienlights oauth link PROVIDERstarts the link. - Galaxy accounts support Google, Apple, GitHub and Okta sign-in. Each one switches on when its client credentials are set.
$ alienlights oauth check --issuer https://accounts.google.com
issuer https://accounts.google.com
result OK
authorization https://accounts.google.com/o/oauth2/v2/auth
jwks_uri https://www.googleapis.com/oauth2/v3/certs
token https://oauth2.googleapis.com/token
userinfo https://openidconnect.googleapis.com/v1/userinfo
jwks keys 1
Use ours
$0 / forever
Sign in with Alien Lights, a standard OpenID Connect provider
- Authorization code flow with PKCE (S256), refresh tokens, a userinfo endpoint and a public JWKS.
- Every token is signed twice: Ed25519 (EdDSA) for ordinary OIDC libraries, and ML-DSA-65 alongside it for post-quantum verification.
- Each identity has its own key pair that rotates monthly, and every change lands in a public Merkle transparency log anyone can verify.
- Users sign up in seconds with no sales call.
issuer https://alienlights.net/api/identity
discovery https://alienlights.net/api/identity/.well-known/openid-configuration
authorize https://alienlights.net/api/identity/oauth/authorize
token https://alienlights.net/api/identity/oauth/token
userinfo https://alienlights.net/api/identity/oauth/userinfo
jwks https://alienlights.net/api/identity/oauth/jwks.json
Client IDs for your own applications are issued by an Alien Lights admin today (alienlights oauth client with an admin token). Self-serve client registration is not built yet.
One identity for everything else
The identity you sign up with is the same one that enrols devices, signs rule sets, produces to Alien Queue and signs you in. Each identity holds its own ML-DSA-65 key pair on your side, and every change to it lands in a public Merkle transparency log. Read how identity works →
Equity Available
One ring per Corp, included free with the platform. There is no extra charge and no platform fee. Your percent of the company is your percent of the profit, paid every month. Paying in and taking out go through Stripe, and the person moving the money pays Stripe's fee.
You see your own stake. A Corp admin sees that Corp's book, and Alien Lights admins are root. Buying equity is a PDF you sign. Equity for work is a PDF the admin issues, with a number of months before it can be sold. The value of a holding follows the latest funding round.
Consultation
The first hour is free. After that, consultation is $100 an hour, paid on this page. We meet on Zoom.
The first consultation includes a free website and a setup demonstration. Please have your SoC or microcontroller dev board with you, or purchase one from us.
We provide simple website builds and a preview, and we show you how to build your site with Cursor. That is free on the first visit. Each website after that is $100 and comes with a free follow-up one-hour consultation.
Book the free hour
Pay for more
Each paid website includes a free one-hour follow-up. The website on the first visit is already included.
Bring your own company.
Alien Lights is one company, and alienlights.net is the root. Everyone else brings their own.
Every company gets two free addresses:
- Production: you@yourcompany.alienlights.net
- Development: you@yourcompany.dev.alienlights.net
A domain you already own is a custom domain at $10 per domain per month, billed through Stripe. You can attach one to production, to development, or to both.
- Two users are included. Each additional user is $10 per month.
- Devices are unlimited.
- There is no storage charge, because we do not store your data.
Equity is one ring per Corp and adds nothing to the bill.
We do not resell Cloudflare. The platform is our own post-quantum zero trust, with our own identity, gateway, agent and message queue. It rides Cloudflare's network. You open no Cloudflare account and get no Cloudflare invoice from them. Galaxy Direct transit on your bill is Cloudflare's published rate (at cost).
Galaxy Direct is post-quantum zero trust network access over the internet, including over-the-air binary flash. Your phone reaches a device on that path, and a signed bin is flashed on that path. Galaxy Direct transit is Cloudflare's published rate (at cost), on all of it. There is no included amount. Nexus transit is free. Bytes your own nodes serve never cross our network, so they are not billed.
Starter
$0 / month
Your company on yourcompany.alienlights.net
- All of it: Zero Trust Access, System on a Chip packages, the PlatformIO plugin, Security Operations, Alien Queue, Starlink IoT, Identity and OAuth, Nexus, and equity (one ring per Corp)
- Two users included, then $10 a month each. Unlimited devices
- Galaxy Direct: you pay for all transit, at Cloudflare's published rate. No included amount
- Your data is not on our bill, because it is not with us
Every Galaxy Direct unit is on the bill. There is no included amount of transit.
Pro
$10 / month, per domain you bring
The same suite on a domain you own. Two users included, then $10 each. Galaxy Direct at Cloudflare's published rate (at cost)
- Everything in Starter, on a domain you already own
- Domains: $10 each, flat. Two domains are $20.
- Users: 2 included, then $10 a month each
- Devices: unlimited, and free
- Galaxy Direct transit: you pay for all of it, at Cloudflare's published rate (at cost), itemized line by line. There is no included amount and no base charge.
- Nexus transit: free
- No egress charges
One invoice. Domains you bring, then users over 2, then all Galaxy Direct transit. Nexus transit is not on it.
Post-quantum transit: Nexus plus your own nodes
Post-quantum transit is Nexus plus nodes that you host. One flag on the zero trust gateway makes it a Nexus node on your own machines:
alienlights-ztna gateway run --nexus --nexus-max-gb 20
alienlights-ztna nexus push app.bin --node https://gw.example.com
The node keeps signed firmware and packages, named by their SHA-256. Your devices fetch from it, and every request is signed with the caller's ML-DSA-65 identity and checked against your own signed rule set. A node stores bytes only if they hash to the name, and clients check the hash again on download, so a node cannot pass off other bytes as your firmware. It can pull what it is missing from an origin once, then serve the rest of the fleet itself. That is Nexus transit, and Nexus transit is free. The same bytes fetched over the internet, through Galaxy Direct, are Cloudflare's published rate (at cost).
| Nexus node | Status |
|---|---|
Gateway runs as a Nexus node with --nexus: signed object cache, pull-through, owner and device access from your rules | Available |
| Push, fetch and inspect from the command line | Available |
| Nexus device sync relayed by your own nodes | Planned |
| Devices find the nearest node on their own. Today you point them at a node by URL | Planned |
Be straight about what this buys. Transit is already cheap, as the tables below show, so a node will not change your bill much. What it gives you is control: your bytes move over your own hardware, on your own network, even with no internet. A node serves signed artifacts, not secrets: seal anything confidential before you store it. Traffic is protected by TLS 1.3. Go offers the hybrid X25519MLKEM768 key exchange by default, so give the node a certificate with --tls-cert to have it end to end. Behind a proxy or a tunnel, the proxy's TLS applies.
The doorbell: why a million devices cost almost nothing to keep reachable
Each device keeps one idle WebSocket open to its own object on the network, the doorbell. While the device is idle, keep-alive pings are answered by the network itself and cost nothing. Nothing runs and nothing is billed. The object wakes only when a device connects or when you ring it, for example to say an update is ready. Then the device downloads the signed bin once. That is why a big fleet stays cheap.
That is why devices are unlimited. A user is a person, not a device. Galaxy Direct bills all of the WebSocket and transit usage at Cloudflare's published rate (at cost). There is no included amount, and the doorbell keeps that usage small. Users over the two included are a flat $10 a month, not a charge per device.
The table below is a fleet that gets an 8 MB signed bin every 6 months, with each device reconnecting 30 times a month. Every figure is a month.
| Devices | Doorbell: Cloudflare rate | Doorbell: you pay (at cost) | You pay per device per year |
|---|---|---|---|
| 100 | $0.02 | $0.02 | $0.0024 |
| 1,000 | $0.08 | $0.08 | $0.0010 |
| 100,000 | $8.24 | $8.24 | $0.0010 |
| 1,000,000 | $82.09 | $82.09 | $0.0010 |
These figures are Galaxy Direct transit only. A domain you bring is $10 a month. Two users are included, then $10 a month each, on yourcompany.alienlights.net as well. Development mail, you@yourcompany.dev.alienlights.net, is free too. On Galaxy Direct, bins are served from object storage with no egress charge, so 1,000,000 devices taking an 8 MB bin is 8 TB per update at no data-transfer cost. The same bin served by your Nexus node is free. Rounded to the cent.
What can move these numbers
The assumption that matters most is how often devices drop and reconnect. Each reconnect wakes the device's object. A healthy fleet sits near the 30 a month used above. A fleet on a bad link can be many times that. This is 1,000,000 devices:
| Reconnects per device | Cloudflare rate / month | You pay / month (at cost) |
|---|---|---|
| 5 a month | $16.39 | $16.39 |
| 30 a month | $82.09 | $82.09 |
| 100 a month | $266.06 | $266.06 |
| 300 a month | $791.68 | $791.68 |
Not in these numbers: sealed metrics, the encrypted reports devices send to your organisation. They are priced separately, kept for 30 days, and capped per organisation. A very large fleet reporting often should send metrics to its own pipeline instead, and use the doorbell and Nexus for what they are good at.
The rates
| What you use | Included each month | Cloudflare rate | You pay (at cost) |
|---|---|---|---|
| Production address | you@company.alienlights.net | — | $0 |
| Development address | you@company.dev.alienlights.net | — | $0 |
| A domain you bring | — | — | $10 / domain / mo |
| Users | 2 included | — | $10 / user / mo after that |
| Worker requests | none | $0.3 / M | $0.30 / M |
| Worker CPU time | none | $0.02 / M ms | $0.02 / M ms |
| Doorbell requests (WebSocket connects and wakes) | none | $0.15 / M | $0.15 / M |
| Doorbell compute while awake | none | $12.5 / M GB-s | $12.50 / M GB-s |
| Doorbell rows written | none | $1.0 / M | $1.00 / M |
| Doorbell stored data | none | $0.2 / GB | $0.20 / GB |
| Bin reads (R2) | none | $0.36 / M | $0.36 / M |
| Bin storage (R2) | none | $0.015 / GB | $0.015 / GB |
| Devices | unlimited | — | $0 |
| Nexus transit | bytes your nodes serve | — | $0 |
| Data storage | n/a | n/a | none, it is yours |
The transit lines are Galaxy Direct, over the internet. You pay Cloudflare's published rate (at cost) on all of it. There is no included amount. Nexus transit is free. Cents are rounded half up, line by line. What your own cloud provider charges you to store your data is between you and them.
How a bill is worked out
- Two users or fewer, on company.alienlights.net or company.dev.alienlights.net, and no Galaxy Direct transit? The bill is $0.00.
- More than two users? $10 a month for each user past the two included.
- Bringing your own domains? $10 a month for each domain.
- Galaxy Direct transit? Multiply all of the usage on each line by the rate you pay. There is no included amount and no base fee.
- Nexus? Transit your own nodes serve is free.
Try your own numbers
What real usage costs
Camp light fleet
$10.46
3 people, 60 devices on Galaxy Direct. One user past the two included is $10. 1.2M requests a month (about 40,000 a day) at 4 ms CPU is 4.8M ms of CPU. Worker requests: 1.2 × $0.30 = $0.36. Worker CPU: 4.8 × $0.02 = $0.10. Transit $0.46, on all of it. Total $10.46.
Maker studio
Free address · $0.00
Two people, ada@studio.alienlights.net and one other. Remote access to 40 boards, signed firmware builds in CI. No domain of their own, and both users are included, so the address is $0.00. Galaxy Direct transit they send is billed in full. There is no included amount.
Company on its own domain
$40.00
The company brings acme.com and has five people. Domain: $10. Users over 2: 3 × $10 = $30. That $40.00 is the domain and the users. Galaxy Direct transit is added on all of it, at the published rate. Their data sits in their own cloud account.
Remote sensors over Starlink
$11.38
One brought domain, two people, and 400 sensors reporting every 5 minutes. That is 288 reports a day each, 3.456M a month, assuming one request per report, at 5 ms CPU (17.28M ms). Requests and CPU come to $1.38, on all of it. The two users are included. Domain: $10.00. Total $11.38.
Growing product, two domains
$26.60
Two people, included. 15M requests at 7 ms CPU, which is 105M ms of CPU. Domains: 2 × $10 = $20.00. Worker requests: 15 × $0.30 = $4.50. Worker CPU: 105 × $0.02 = $2.10. Total $26.60. Galaxy Direct transit at Cloudflare's published rate, on all of it: $6.60. The same bytes on Nexus would be $0.
High-traffic network, three domains
$74.00
Two people, included. 100M requests at 7 ms CPU, which is 700M ms of CPU. Domains: 3 × $10 = $30.00. Worker requests: 100 × $0.30 = $30.00. Worker CPU: 700 × $0.02 = $14.00. Total $74.00. Galaxy Direct transit at Cloudflare's published rate, on all of it: $44.00.
The calculator counts domains, users over 2, and Galaxy Direct Worker requests and CPU time. It does not model the doorbell, which is in the fleet table above, or sealed metrics. Nexus transit is free and is not added.
Field of use: IoT lighting and WLED derivatives
IoT lighting is our vertical, and it pays for this platform. The platform is for everything else you build and run. So the Services are not licensed to anyone to compete with Alien Lights in that field. By signing up you agree to this:
- The restricted field. Designing, making, selling or operating connected or addressable lighting products or services, or firmware that is a fork or derivative of WLED, for other people.
- What you agree not to do. While you use the Services, and for 12 months after you stop, you will not use the platform, or anything you got through it (the gateway, Alien Queue, the Factory, signed images, the doorbell, Nexus, Galaxy), to build or run a business in the restricted field.
- What is always fine. Managing your own lighting, such as the lights in your own buildings, venues or vehicles. Building anything outside the restricted field. Using WLED itself. This does not limit anyone's rights under the WLED open-source licence. It limits what you do with our services.
- Want to build in this field anyway? Do it with us. The Build the Future page explains how: build inside the Alien Lights ecosystem and share in the profit, or build your own company with us as the foundation. Without a written agreement, the restriction applies.
- If a court says part of this is too broad, it is cut back to what the law allows. The rest stays. This restriction does not apply where the law of your place does not allow it.
If you make WLED devices or lighting products, start at Build the Future.
Prohibited uses: no military, spying, corporate espionage, patent copying or suppression of activists
Alien Lights and the services behind it (mail, the gateway, Galaxy, Alien Queue, Nexus, Alien Poke, Alien VPN, the Factory and signed images) exist to protect people. They may not be used against them, or to take what other people have built. By signing up, or by installing or using the apps or agents, you agree to this:
- No military use. Military means military, in the ordinary sense of the word. You will not use the Services, or anything you got through them, for any military purpose of any kind. That covers armed forces, military intelligence, defence ministries and the contractors and suppliers working for them; combat, defence, logistics, training, communications and weapons work alike; and any country, ally or cause. It does not matter whether the use is offensive or defensive, large or small, or paid or free. There are no exceptions.
- No spying. Spying means spying, in the ordinary sense of the word: secretly watching people or organisations, or secretly collecting, intercepting or tracking information about them. You will not do it with the Services, whoever you are: a government, an intelligence or security service, a company, or an individual. That covers espionage, covert monitoring, stalkerware, and surveillance of anyone who has not been clearly told. There are no exceptions for any customer, country or cause. Openly managing devices you own, where the people using them know, is not secret and is not spying.
- No corporate espionage. Corporate espionage is spying on a company. You will not use the Services to steal, obtain or leak another company's trade secrets, confidential information, source code, designs or customer data, or to get into its systems or people's accounts without permission. This is part of the ban on spying and has no exceptions either.
- No copying of patented products. You will not use the Services to copy another company's patented product, or to design, make, sell or run anything that infringes another company's patent. That includes using the platform to reverse engineer a product in order to copy it, to build or distribute the copy, or to manage a business that sells it. Making your own product, building something different, and using what you hold a licence for are fine. So is using an invention whose patent has expired or been held invalid.
- No suppression of activists. You will not use the Services to identify, locate, monitor, intimidate, harass, silence, detain or retaliate against activists, journalists, human rights defenders, dissidents, protesters or others for their lawful speech, reporting, organising or beliefs.
- What happens if you do. We may suspend or revoke your identity and organisation, refuse service, and remove your access to signed packages and queues, without notice and without a refund. We will not read your sealed data to decide this, because we cannot. We act on what is shown to us: reports, public facts, and your own account activity.
- Reporting. If you believe the Services are being used this way, tell us through the contact on the privacy page. Do not include anyone's secrets.
- These terms travel. They apply to anyone you give access to, and to anything you build on the Services for others. They apply even where another licence covers parts of the software, because this limits what you do with our hosted services and signing keys, not anyone's rights in open-source code.
- If a court says part of this is too broad, it is cut back to what the law allows. The rest stays. This does not apply where the law of your place does not allow it.