Security, SSO & Isolation

Five layers, in order

1. The registry gate. Images are vulnerability-scanned when pushed; critical CVEs block deployment before anything reaches your workspace. How scanning works →
2. The sandbox. Custom containers run in a sandboxed runtime by default: an interception layer between your container and the host kernel, the same class of technology the big clouds use to run untrusted code. A native-runtime opt-out exists for the rare app that needs it.
3. The network. Internet egress is off by default: your app reaches the other apps in your workspace and DNS, nothing else, until you deliberately enable it. Inbound is equally explicit; an app is only reachable from the internet if you toggle its public URL on, and platform policy prevents one workspace's apps from ever addressing another's.
4. The quota. Resources are guaranteed and capped at your chosen tier, per app, with workspace-level ring-fencing above that. A runaway process in one app exhausts its own tier, not your workspace and not the platform.
5. The policy engine. Estate rules (images only from your own registry, no privileged containers, resource limits mandatory) are enforced by admission policy at the platform layer. Deployments that violate them are refused automatically; there is no "unless someone was in a hurry".

Single sign-on: one toggle, your whole workforce

Every node.uk workspace has its own identity realm, the same login your team already uses for their CRM, files and helpdesk. The deploy form has an SSO toggle; switch it on and your custom app sits behind that realm too:

• Visitors must authenticate with your workspace accounts before any request reaches your container, so your app needs no login code at all.
• Grandfathered internal tools with no auth, admin dashboards, staging builds: safe to expose, because the platform does the authentication.
• Joiners get access with their workspace account; leavers lose it the moment you disable them: one place, every app, including yours.
• If you federate Microsoft Entra ID, Google Workspace or LDAP into your realm, that federation covers your custom apps automatically.

Backups, monitoring, and the boring essentials

Every custom app inherits the estate policy that covers our own apps: nightly backups of the app and its volumes (included in the storage price, visible in your portal), resource and availability monitoring, centralised log shipping, and TLS certificates issued and renewed without you thinking about them. If we'd page ourselves for it on a catalogue app, it's watched on yours too.

UK metal, UK company, one throat to choke

Your container runs on hardware we physically own in our UK datacentre, not a reseller layer over a US hyperscaler. One UK company operates the whole stack from the metal up, under a clear Article 28 DPA, and the engineers who built the platform are the ones who answer your tickets. For regulated and jurisdiction-sensitive workloads, that's the difference between a compliance answer and a compliance essay.

Frequently asked questions

How is my app isolated from other customers?

Structurally, at several layers. Your apps run in your own private workspace with its own network; other customers' traffic never crosses it. Containers run in a sandboxed runtime by default, which puts a second wall between your workload and the host. Resources are ring-fenced per workspace, so a noisy neighbour can't slow you down, and policy enforcement at the platform level means these aren't conventions: deployments that break the rules are refused.

What is the sandboxed runtime and does it cost performance?

Custom containers run inside an additional isolation layer that intercepts what the container asks the host to do, an industry-standard approach for running third-party code safely. Typical overhead is small (single-digit percent for most web workloads, more for syscall-heavy ones). If your app is incompatible or you need every last percent, a native runtime opt-out exists; talk to us.

How does the single sign-on toggle work?

Every workspace has its own identity realm on our managed Keycloak platform. Flip the SSO toggle on a custom app and visitors must sign in with your workspace accounts before a single request reaches your container. Your app needs no auth code of its own, and removing a leaver from your workspace removes their access to it instantly: the same one-login story as every catalogue app.

Why is internet access off by default for my app?

Because arbitrary outbound access is how compromised containers exfiltrate data, join botnets or mine cryptocurrency. Your app can always reach the other apps in your workspace and DNS; if it legitimately calls external APIs, you switch internet egress on with one toggle. Deny-by-default means the decision is yours and it's deliberate.

What about vulnerabilities in my image?

Scanned on push, blocked at critical severity; see the private registry page for the full flow. The gate sits in front of deployment, so a critically vulnerable image never reaches your workspace in the first place.

Are my app and its data backed up?

Yes. Custom apps and their volumes are covered by the same nightly backup schedules as everything else in your workspace, and backup status is visible in your portal. Storage prices include the backup; it's not a paid add-on.

Where does my app physically run?

On servers we own, in our UK datacentre, operated by our own engineers, under a UK company and a clear Article 28 data processing agreement. There is no hyperscaler beneath us: jurisdiction isn't a region checkbox here, it's the ownership structure.

Security questions? Ask an engineer.

Threat model, isolation details, compliance evidence for your security review: you'll be answering to the people who actually run the platform.

Name*

Company Name*

Phone Number*

Email Address*

Message*

Get more detail