Ask a vendor where their platform runs and you will usually get one word back: cloud. It is a good answer to a question nobody asked. The questions that actually decide a deployment come next — whose cloud, which region, what happens on the factory floor when the link to it drops for four hours, and who owns the machine the data is sitting on at 3am when an auditor asks.
Redstone answers differently, and the answer is a list rather than a word.
What "everywhere" actually means
Redstone 5.1 is a supported deployment on all of the following, from the same release:
| Target | Where it typically lands |
|---|---|
| Windows x64 | Existing on-prem servers, corporate VM estates, Windows-shop IT departments |
| Linux x64 | Data-centre and cloud-tenancy workloads, containers, the majority of production |
| Linux ARM64 | Raspberry Pi and other single-board computers, ARM cloud instances, edge nodes |
| macOS | Developer and integrator machines — building and testing against real workflows |
And in three shapes: as a headless API server, in console mode, or with its full interface. The platform does not mind which; the deployment decides.
One codebase, not four ports
The reason that list stays consistent is that there is nothing to keep consistent. Redstone is a single .NET 10 codebase compiled for each target — not a Windows product with a Linux port trailing eighteen months behind it and an ARM build that exists in a slide deck.
This matters more than it sounds. Cross-platform claims usually decay into a hierarchy: one platform gets the features, the others get the ones that were easy to carry across. You find out which tier you bought into about six months in, when the connector you need turns out to be Windows-only. On Redstone, a workflow authored on a developer's laptop, tested in a Linux container and deployed to a Raspberry Pi in a plant room is the same workflow definition, byte for byte. The runtime underneath it changes; the platform above it does not.
Headless is the default, not a stripped-down build
A lot of "runs on Linux" software runs on Linux the way a fish runs on land — technically alive, visibly unhappy, and quietly expecting a display server to be there. Redstone's headless mode is not a reduced edition. It is the same platform with no interface attached: no desktop session, no display server, no GUI dependency chain to install on a machine whose only job is to answer API calls.
That is what makes the small end of the hardware range viable. A node with a gigabyte of RAM and no screen is a perfectly ordinary Redstone host, because nothing is being started that needs a screen.
The Raspberry Pi is not a demo
This is the part people assume is marketing. It is not — it is one of our delivery patterns.
We build in-house control systems on Raspberry Pi driven by Redstone: power, lighting, magnetic door access and CCTV surveillance, managed from one platform. Not a gateway shipping telemetry to a cloud service that does the real work — Redstone itself, running on the board, holding the logic, enforcing the rules, and continuing to enforce them when the uplink is down.
The same is true of kioskware. A locked-down self-service terminal for check-in, ordering or payments is a Redstone host like any other, and central management and monitoring come from the platform rather than from a separate device-fleet product.
So the estate you end up with is not one platform for the office and another for the edge. It is one platform at several sizes: a developer laptop, a rack in your own server room, a node in your cloud tenancy, a board screwed to the wall behind a door reader. Same governance, same audit trail, same upgrade path.
What portability actually buys you
- The economics of ARM. The cheapest compute per unit of work now lives on ARM64, in the cloud and on the bench. Redstone treats ARM64 as a first-class target, so that saving is available to you rather than to a vendor's roadmap.
- Hardware you already own. Portability means the machine you have is usually a candidate, and a deployment that fits an existing VM estate needs no procurement cycle in front of it.
- Air-gapped and offline operation. If the platform can run on a board with no uplink, it can run in a facility with no uplink — a disconnected site, a regulated environment, a network that will never be allowed out.
- No dependency you did not choose. Your data sits where you put it, on infrastructure under your control. Terms cannot change under you, and access cannot be withdrawn by somebody else's policy decision.
- Recovery without a rebuild. A deployment that runs on four targets can be stood back up on whichever one you can get your hands on — a disaster-recovery property nobody thinks to write into the disaster-recovery plan.
The honest part: what does differ
Portability is not a claim that every host is equivalent, and it would be a poor engineering answer to pretend otherwise.
- Throughput follows the hardware. A Pi and a 32-core server run identical logic at very different rates. Sizing is still sizing. What portability removes is the need to change platform when you change class of machine.
- Some security features come from the operating system. The post-quantum algorithms Redstone 5.1 exposes (ML-KEM, ML-DSA) are available where the host OS provides them, so the machine underneath still sets the ceiling on that particular capability.
- macOS is a build-and-test target. Fully supported for development and integration work. We do not recommend it as a production host, and we will say so in a design review.
- Pinned native dependencies are the real constraint. If a custom connector wraps a native library that only ships for one architecture, that connector — not the platform — is what limits where the deployment can go. Worth flagging early: it is the one case that needs work rather than a recompile.
One platform, one upgrade path
All of it sits on the commitment that makes it useful over time: up to 10 years of LTS on one continuously maintained upgrade path. The Windows server, the Linux container and the board behind the door reader move forward together, on the same release. Customers who adopted Redstone six or seven years ago are on the current version today — one supported platform in the field, not a trail of fragmented versions per architecture.
That is the whole argument for portability, in the end. It is not about collecting operating systems. It is about never having the conversation where a good idea dies because the platform it would have to run on cannot go where the work is.
If you have a site, a device or a network where the work happens and your current platform cannot follow it there, get in touch. Tell us what the machine is and where it sits, and we will tell you plainly whether Redstone belongs on it.