How to deploy. How to operate. How to leave.

The shortest possible path from nothing to a server you can SSH into is four steps. None of them require talking to a human. None of them require an identity document.

1. Create an account. Email and password. The email is for breach notifications and warrant-canary alerts only — we never use it for marketing.
2. Top up your balance. We do not store payment methods. You send any supported cryptocurrency to a one-time address; we credit your account balance in USD-reference once the deposit is confirmed.
3. Deploy a server. Pick a plan, a region, an OS image, paste an SSH public key. Provisioning takes 30–90 seconds.
4. Connect. SSH to the IPv4 the dashboard shows you. Log in as root on the SSH key you uploaded.

Sign-up

Email + password. The password is hashed with bcrypt (cost factor 12). The email is normalised to lowercase, hashed for lookup, and never stored next to plaintext. We do not check the email is "real" beyond a basic syntax pass — you are free to use any address you control.

Sessions

Logging in creates a 30-day rolling session bound to a per-device secret stored in a HttpOnly, Secure, SameSite=Lax cookie. Each browser is a separate session; you can list and revoke them from Account → Security.

Two-factor authentication

Two options:

• TOTP — RFC 6238, 30-second window, SHA-1 (compatible with every authenticator app). Recovery codes are generated once at setup and shown only that one time.
• WebAuthn (FIDO2) — hardware keys, platform authenticators (Touch ID, Windows Hello). Multiple keys can be registered.

When 2FA is enabled it is required for: login, password change, API-token creation, and account deletion. It is not required for deploying servers from an active session — that would be the wrong place to slow you down.

Account deletion

Deletion is self-service from Account → Security → Delete account. The flow:

1. All servers are destroyed (irreversible, no grace period).
2. Remaining balance is forfeited (we have no way to send it back — crypto refunds require an address you've authenticated, which would itself be a KYC step).
3. The account row is replaced with a tombstone (id + deletion timestamp). Email hash, password hash, sessions, tokens, SSH keys: gone.
4. Billing ledger entries are retained for 13 months for fraud reconciliation, with no PII attached.

Top-up flow

From Account → Billing → Top up:

1. Pick a coin and an amount (USD-reference).
2. We generate a one-time receive address and lock the rate for 30 minutes.
3. You send funds. We watch for the required confirmations (see table below).
4. Once confirmed, your account balance is credited at the locked rate. Any surplus is credited at the spot rate at confirmation time.

Supported coins & confirmations

Daily-charge model

You are charged once per UTC day for the prorated daily cost of every running server you own. The charge happens at 00:00:01 UTC against your balance.

• If you have enough balance, the charge succeeds silently.
• If you don't, you receive a warning email and the server is marked suspended. It stops billing and stops accepting traffic.
• You have 7 days to top up. After 7 days the server is destroyed, its IPs released, and its disk wiped.

Ledger

Every line item is in Account → Billing → Ledger: top-ups, daily charges per server, SLA credits if applicable. Each row has a stable id you can reference. Exportable as CSV.

Deploy

From Configure on any plan, or via the API. A new server moves through these states:

• provisioning — we are allocating the VM. 30–90 seconds.
• installing — OS image is being written and cloud-init is running. 30–120 seconds.
• running — server is up; SSH is reachable.
• stopped — gracefully shut down. No CPU/RAM bill while stopped, but the disk and IP are still allocated and billed.
• suspended — balance went negative. Server is off and not reachable. 7-day grace period before destruction.

Reboot & rebuild

Two operations, often confused:

• Reboot sends an ACPI shutdown signal to the guest, waits 30 s, then powers it back on. Disk contents are preserved. Add ?hard=true on the API call (or the "Hard reset" toggle in the UI) to skip the ACPI step.
• Rebuild reinstalls the OS image from scratch. All disk data is destroyed. Cloud-init runs again. This is what you do when you want a fresh start without re-creating the server (keeps the same IPv4 and IPv6).

Rescue mode

Rescue mode boots the server from a small Alpine-based ISO into a 4 GB tmpfs. Your disks are unmounted and visible at /dev/vda, /dev/vdb, etc. Use it to:

• Recover a system you've locked yourself out of (forgotten root password, broken sudo, etc.).
• Unlock a LUKS-encrypted root volume manually.
• Run fsck against a broken filesystem.
• Image-dump a disk you're about to destroy.

Exit rescue mode by issuing a Reboot. The next boot picks the normal disk again.

Destroy

Destruction is irreversible. The disk is overwritten with zeros, the IPv4 returns to the pool after 24 hours of cooldown (to prevent immediate reuse of an address you may have published in DNS), and the IPv6 /64 returns to the pool immediately. The server's billing entry is closed at the timestamp of destruction.

Every server is provisioned with key-based SSH only. Password authentication is disabled in the default sshd_config we ship; you are free to re-enable it, but we strongly recommend you don't.

SSH keys

Add keys at Account → SSH keys, paste any OpenSSH-format public key. We accept:

• ssh-ed25519 — recommended. Short, fast, modern.
• ssh-rsa — 3072 bits or more. (Anything smaller is rejected.)
• ecdsa-sha2-nistp256 / nistp384 / nistp521 — accepted but discouraged.

Multiple keys per account. Multiple keys per server. Any key on the server's authorized list can log in.

Recommended ~/.ssh/config

Host nokyc-*
    User root
    IdentityFile ~/.ssh/id_ed25519_nokyc
    IdentitiesOnly yes
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m
    ServerAliveInterval 60
    ServerAliveCountMax 3

Then for a server with IPv4 198.51.100.42:

Host nokyc-edge
    HostName 198.51.100.42

And ssh nokyc-edge just works.

Rescue-mode SSH

The rescue ISO injects the same set of SSH keys at boot. The rescue host fingerprint is different from your normal host fingerprint — this is expected and not a man-in-the-middle. The rescue fingerprint is shown on the console in the dashboard.

IP addressing

• IPv4 — one per server, included in the plan. Additional IPv4 is not currently sold (we are conservative with v4 allocation).
• IPv6 — one routed /64 per server, free. Use whatever addresses inside that prefix you like; we don't filter source addresses within your block.
• All addresses are static for the life of the server. Rebuilding the OS does not change them.

Reverse DNS

From Server → Network → Reverse DNS, or via POST /servers/{id}/rdns. We propagate within 5 minutes. There is no validation that you actually control the forward record — the rDNS is yours to set as you like.

Firewall

Two layers:

1. Edge filter (optional, configurable per server). Stateful, drop-by-default with the rules you provide. Lives on the hypervisor and protects the guest from receiving the traffic at all. Use it for layer-4 rules you want enforced before the guest even sees the packet.
2. Guest firewall (entirely yours). nftables, iptables, pf, whatever your OS ships. We don't touch it.

DDoS mitigation

Volumetric-attack mitigation is always-on, upstream of our PoPs. There is nothing to enable. The thresholds:

• < 10 Gbps: absorbed silently.
• 10–100 Gbps: scrubbed at the transit provider. You may see brief latency increases.
• > 100 Gbps: announced via BGP to a dedicated scrubbing path. Latency increases more noticeably; service remains reachable.
• The "nuclear option" of null-routing an IP is on the table only for sustained attacks that threaten the wider PoP. We tell you within minutes if it happens.

The image catalogue is refreshed on every upstream point release. The image_id in the right column is what you pass to the API.

cloud-init user-data

Any image marked "cloud-init" accepts a user-data blob at deploy time. Up to 64 KiB. Example for a Debian server that installs WireGuard and sets a hostname:

#cloud-config
hostname: edge-paris
manage_etc_hosts: true

package_update: true
packages:
  - wireguard
  - nftables
  - mosh

write_files:
  - path: /etc/wireguard/wg0.conf
    permissions: '0600'
    content: |
      [Interface]
      PrivateKey = REDACTED
      Address    = 10.10.0.1/24
      ListenPort = 51820

runcmd:
  - systemctl enable --now nftables wg-quick@wg0
  - sed -i 's/#PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
  - systemctl restart ssh

Custom ISOs

Upload via POST /images (or Account → Images → Upload). Maximum 4 GiB. The ISO must be bootable in BIOS or UEFI mode (we present both). Once uploaded, the image gets an id like custom-9f4a2b1c and is selectable in any deploy flow.

REST over HTTPS. JSON in, JSON out. Cursor-pagination on list endpoints. Idempotency keys supported on every POST via the Idempotency-Key header.

Base URL

https://api.nokycvps.com/v1

Tor onion mirror

nokycvpsapixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/v1

TLS

TLS 1.3 minimum. Certificate pinned to our intermediate CA — published in DNS via TLSA records.

Schema

OpenAPI 3.1 spec at /v1/openapi.json

Authentication

Bearer token, header Authorization: Bearer <token>. Tokens are created at Account → API tokens with one of three scopes:

• read — read-only access to all resources except billing.
• write — read + create/update/destroy. Cannot generate new top-up addresses.
• billing — everything write can do, plus billing endpoints.

A token is shown once at creation. We store only its SHA-256 digest server-side; if you lose a token, rotate it.

Endpoints

Examples

Create a server:

curl https://api.nokycvps.com/v1/servers \
  -H "Authorization: Bearer $NOKYC_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name":     "edge-paris",
    "plan":     "vps-s2",
    "region":   "par",
    "image":    "debian-13-minimal",
    "ssh_keys": ["k_5f3a8c91"],
    "user_data_b64": null
  }'

Response (HTTP 201 Created):

{
  "id":         "srv_8a1f2c34",
  "name":       "edge-paris",
  "status":     "provisioning",
  "plan":       "vps-s2",
  "region":     "par",
  "image":      "debian-13-minimal",
  "ipv4":       null,
  "ipv6":       null,
  "created_at": "2026-05-12T08:47:12Z",
  "ssh_keys":   ["k_5f3a8c91"]
}

Reboot it:

curl -X POST https://api.nokycvps.com/v1/servers/srv_8a1f2c34/reboot \
  -H "Authorization: Bearer $NOKYC_TOKEN"
# 202 Accepted

Error codes

All errors return JSON in the shape {"error": {"code": "...", "message": "...", "errors": [...]}}.

Rate limits

60 requests per minute per token, with a 10-request burst. The bucket replenishes at 1 req/s. The headers on every response:

X-RateLimit-Limit:     60
X-RateLimit-Remaining: 57
X-RateLimit-Reset:     1747049892

If you exceed the bucket, you'll receive HTTP 429 with a Retry-After header in seconds. Provisioning endpoints have a separate, more permissive bucket (200/min) because they are inherently bursty.

Disk encryption

We do not encrypt your disks for you. You can opt into LUKS at install time via cloud-init (the rescue ISO will prompt you for the passphrase on every boot). The reasons we don't auto-encrypt:

• Auto-encryption with a key we hold is theatre — if compelled, we can produce the key.
• Auto-encryption with a key you hold breaks unattended reboot.
• Both modes are available; we let you pick the trade-off.

Warrant canary

We publish a daily-signed canary at https://nokycvps.com/canary.txt with a detached PGP signature at canary.txt.sig. The canary includes:

• A current-date timestamp.
• The headline of a current event we couldn't have predicted in advance (proof of liveness).
• A list of explicit statements about orders we have not received.

When one of those statements would become false, we let the canary stop updating instead. Treat extended silence (> 48 hours) as a signal.

Tor onion mirror

The site and the API are both mirrored as v3 onion services. The hostnames are published in our DNS as TXT records on nokycvps.com and rotated yearly. From a Tor-routed client:

dig +short TXT _onion.nokycvps.com
# "v3 nokycvps...........................................onion"
# "v3 nokycvpsapi........................................onion/v1"

What we log

Concisely:

Written by people who actually run this stuff. Each one is a single, copy-pasteable walk-through — no fifty-tab marketing detours.