Graviton — The Architecture Behind Every Stardeck App
Graviton 9.6
One system behind every app you run. Built to get newer, not older.
01 / One system, many apps
Your business isn’t one app. Graviton isn’t either.
The storefront your customers browse, the counter your staff ring up on, the dashboard you check at closing time. Each one gets its own address and its own way in. All of them run on one system, over one set of data.
Storefront
acme.stardeck.site
What your customers see. Public, fast, and found by search.
Point of sale
acme-pos.stardeck.site
Opens like an app on the counter iPad. No app store, no install day.
Admin
acme-admin.stardeck.site
Only your team gets in, signed in through your organisation.
Staff app
acme-staff.stardeck.site
For drivers and floor staff, on the phones they already carry.
02 / Everywhere at once
No server. No region. No 2am.
Your app isn’t a machine in a data centre somewhere, waiting for traffic to find it. It runs at the edge of the network, so a request is answered close to wherever your customer happens to be standing.
Nothing to size
No instance types, no capacity planning, no guessing at your busiest hour. There is no machine to make bigger.
Checked before it runs
Who is signed in, and whether they are allowed on that address at all, is settled one step before your app is involved.
Nothing to patch
Nothing to patch and nothing to upgrade, so there is no maintenance window to warn your customers about.
03 / It gets newer, not older
Most software starts aging the day it ships.
You know the pattern: a system built five years ago that nobody dares touch, running a version nobody supports. Graviton is built the other way round. More than a hundred upgrades have shipped so far, and every app on the platform is carried forward to the same version.
The platform moves, your app moves with it
When we ship a better way to take payments or send email, it doesn't sit in a changelog waiting for you to notice. It's an upgrade written for your app.
Breaking changes rewrite themselves
When something has to change shape, the upgrade carries instructions and an agent rewrites the code that used the old way. You approve, you don't rewrite.
Every app converges on the same version
One app built last year and one built this morning end up on the same footing. There is no fleet of one-off builds slowly drifting apart.
04 / For the engineers
Still reading? Good. Here’s where the line sits.
Every platform draws a boundary between what it handles and what you own. This is ours, drawn to scale.
Below the line / Graviton’s
Identity
Resolved at the boundary. A handler never sees a request it was supposed to reject.
Access
Hostname and audience rules enforced before your code is invoked, not inside it.
Scale
No instance sizes, no regions, no policy to tune. The busiest hour looks like any other.
Operations
No hosts to patch, no runtime to upgrade, no maintenance window to announce.
Portability
Features move between apps with their routes, tables, translations and seeds intact.
Verification
Real code paths against a real database. A verified commit stays verified.
Versioning
Upgrades are written for your app. Breaking ones rewrite the call sites.
Above the line / Yours
Product code
Data model
Design and copy
That’s the whole list.
And the honest constraints
- The runtime is the edge, not Node, so libraries that need Node's runtime don't run. That trade is what buys the left-hand column.
- Schema changes are made through the platform rather than in app code, so the change lands on the same branch the app reads from.
Every app we build runs on this.
Tell us what your business actually does. We’ll show you what it looks like on Graviton.