Security

This page describes the controls that exist today and names the ones that do not. It is deliberately not a list of everything a security page usually promises. When a control lands, it moves from the second list to the first and the version date changes.

1. What exists today

Your identity and your account

• A second factor: time-based one-time codes from an authenticator app, per account, with single-use recovery codes issued beside them.
• Session control. Every session is recorded with its device and last-seen time; you can see them and revoke any of them from your settings. A revoked session stops working at the next request.
• Re-authentication before sensitive changes to the account.
• A per-account audit log of every action taken on your account, by whom, from where, and what it did — including actions an operator takes on your behalf.
• A backup email you can name, who is written to if the account is misused or compromised, and who need not hold an account.
• Rate limits on sign-in and one-time codes, and a human check on every public form.

Isolation between tenants

• Each workspace is a KVM virtual machine with its own kernel and its own disk. Tenants share physical hardware; they do not share a kernel.
• Each workspace runs its own WireGuard endpoint for the people who use it.
• Commands from this console to a host are signed with a key held by that host; a wrong or replayed signature is refused.
• Each workspace’s disk has a fixed size, so one tenant cannot exhaust a host.

Network and transport

• Every workspace gets a public IPv4 address of its own, forwarded to it on every port. On some plans it is included in the price and on others it is charged on top; the pricing page says which.
• TLS everywhere: the console sends Strict-Transport-Security with preload, a content-security policy, and frame denial; workspace domains get certificates from Let’s Encrypt automatically.

The control plane

• Credentials are held in the environment or in an untracked, root-owned configuration file, never in a tracked file, and the configuration layer refuses to answer a credential to code that did not declare it needs one.
• Cross-site request forgery protection on every state-changing request.
• Operator actions are audited, and an operator acting as a customer is recorded as such.
• Deleting a workspace is verified against the host before the console reports it done.

Snapshots — what they are, precisely

• You can take a snapshot of a workspace at any time from its Snapshots tab, and roll back to it.
• Automatic daily snapshots are off until you switch them on, per workspace. They run once a day and are kept for 1, 3, 7 or 14 days. Up to 3 days is included in the plan price; 7 days adds 20% and 14 days adds 45% to that workspace’s plan price.
• Every snapshot is stored on the same host, in the same disk chain, as the workspace it belongs to. It undoes a bad change; it does not survive losing the host.

2. What does not exist yet

Each of these is true as of the version date above.

• No SOC 2, ISO 27001 or any third-party certification or attestation. We cannot supply an audit report, and we say so in the DPA.
• No service level agreement. No uptime commitment and no service credits.
• No off-host backups. Nothing copies your workspace, or its snapshots, to another host or another location. Losing a host loses the workspaces on it and their snapshots. Keep a copy of what matters somewhere we do not control.
• No encryption at rest that we manage. Workspace disks are not encrypted by us on the host. If you need it, encrypt inside your machine.
• No dedicated DDoS scrubbing beyond what the datacenter network provides.
• No bug bounty. Responsible disclosure is welcome and credited; there is no paid programme.

3. Roadmap

What is planned, in order. There are no dates here because we have not committed to any; an item moves to section 1 when it ships, and this page’s version date changes.

1. Next: off-host backups. Encrypted copies of each workspace kept on a different host in a different location, with a restore we test on a schedule. This is the gap we hear about most from teams moving off AWS, and it is first for that reason.
2. A measured availability record, published once we have 90 days of one. The status page shows what we can observe today.

Not planned yet: a third-party certification, an SLA, DDoS scrubbing and a bug bounty. If that changes, it appears in this list first.

4. Shared responsibility

We secure the hardware, the hypervisor, the network, the control plane and this console. You secure the machine: its packages, its users and keys, the services you expose, the secrets you store on it, the agents you connect to it. A root box with an unpatched service on a public address is compromised in hours regardless of what we do underneath it.

5. Incident response

When we learn of an incident we contain it first, then tell the customers affected — to the account email and the named security contact — without undue delay, and within 72 hours where the DPA applies. Incidents that meet the thresholds in the CERT-In directions of 28 April 2022 are reported to CERT-In within the time they require. Status during an incident is communicated by email and on the public status page, which lists incidents and shows what the console can observe of the platform.

6. Reporting a vulnerability

If you find a weakness in the console, the control plane, the network or the hypervisor, write to abuse@selfmade.ninja with “Security” in the subject. Tell us what you found and how to reproduce it; do not access other tenants’ data or degrade the service to prove a point. We acknowledge within two business days, keep you informed, and credit you when it is fixed if you want us to. We do not pursue researchers who follow these rules in good faith. Abuse by a tenant — spam, an attack from one of our addresses — is a different thing; see the Acceptable Use Policy.