What changed, and when.

Every VPS now has a Usage tab: a simple graph of how much data went in and out of your server each day for about the last month, with running totals and your busiest day.

We show bandwidth and nothing else, on purpose. It is the only usage figure the provider reports over its API — there is no CPU, memory, or disk graph to be had, so rather than draw empty axes for numbers we cannot get, we tell you that’s where the line is. The graph is plain, loads with the page, and hovering a bar gives you the exact figure.

You can now add DDoS protection to a VPS when you order it — network-level mitigation for volumetric attacks, for $15/mo.

Two honest notes, because they matter. It’s available only in certain locations, so if the location you picked doesn’t support it, we decline the order and don’t charge you, rather than taking your money for something we can’t switch on. And it’s set when the server is built, so it’s an at-order choice rather than something to toggle later.

Adding an SSH key meant pasting a long base64 string without mangling it. GitHub already publishes the public keys on every account, so the SSH keys tab on your VPS now takes a username instead: type it, and we copy the keys across. They show up in your key list tagged with where they came from.

Two things worth being clear about.

We copy the keys once. We do not stay linked to the account. If you add a key on GitHub later, come back and import again. This is deliberate: GitHub releases usernames when an account is deleted, and anyone can register a released name. A permanent link would mean your server quietly accepting a stranger’s key the next time it was rebuilt, just because the original owner closed their account.

Use an account you control. We do not check that the username is yours, because we cannot — the keys are public. Anyone who can sign in to that GitHub account can sign in to your server.

Pasting a key by hand still works exactly as before, and we now spot a key you have already added even if you gave it a different comment the second time.

Clicking Actions, or any tab, on a VPS was slow — sometimes ten to thirty seconds. Behind the scenes the page was rebuilding the entire operating-system list and the entire one-click-app catalogue from scratch on every single load, and on top of that pulling a list of every server on the account just to read one field. All of it over a provider API that answers in seconds, one call after another.

The catalogues change a handful of times a year, so we now cache them the way we already cache the region list, and refresh in the background. The whole-account lookup is now a single-server lookup. The page shows the same things — we just stopped fetching the parts that hadn’t changed.

New VPSes come up with a candor sudo user instead of a root login. That user was being asked for a password every time it ran sudo — and the password was a random string you had to go and fetch from the portal, which is not a security control so much as a reason to give up and use root.

It now runs sudo without prompting, the same as the default account on every mainstream cloud image. Your SSH key is the credential that matters; once you’re on the box, sudo gets out of the way. The password still exists for recovering the account from the provider console, and root over SSH stays off.

This applies to servers built or reinstalled from now on. A server you set up earlier keeps asking until you reinstall it, or you can drop the prompt yourself with one line in /etc/sudoers.d/.

You could give us an SSH key when you ordered a VPS, and after that there was nowhere to add a second one — a new laptop, a colleague, a CI runner. Every VPS now has an SSH keys tab where you can add and remove keys yourself.

Keys are written onto the server by cloud-init, which only runs when the server is built or rebuilt. We say that on the page rather than letting you find out, and we give you a copy-paste command that authorises the same keys on a server that is already running.

The bigger fix is underneath. Reinstalling a server used to hand it back with whatever login it was originally built with — for anything built before we switched to a sudo user, that meant root with a password. A reinstall now writes your current keys and a fresh sudo login before the rebuild starts, so the server comes back the way your portal says it is. If we cannot do that, we refuse the reinstall and tell you, instead of quietly rebuilding you into something else.

Windows servers are left alone by all of this — they do not run cloud-init, and we would rather show you nothing than a login that was never created.

Backups being included is something we say on the pricing page, so it should not depend on anyone remembering to enable them. New VPSes are created with automatic backups already switched on, and you can see the schedule and history on the Backups tab of your service.

The cost is in the plan price, as it always was — there is no separate backup line on your invoice.

One honest limit: our smallest legacy plan could not support automatic backups at all, which is part of why it is no longer sold.

Two new tabs on any VPS.

Network lists the IPv4 and IPv6 addresses on your server with their netmask and gateway — including the extra IPv4 addresses you bought, which you previously had no way to see. Reverse DNS is editable per address, which matters if you send mail from the server: it is one of the first things receiving mail servers check.

Firewall puts a default-deny firewall in front of the server. Turning it on opens SSH, HTTP, HTTPS and ping first so you cannot lock yourself out, and then you add or remove rules as you need them — protocol, port or port range, and which addresses are allowed. Every rule belongs to your server alone.

Reinstalling or changing the operating system now asks for confirmation first. Both wipe the server, and neither used to warn you.

A server whose only account is root, reachable over SSH with a password, is the single most scanned target on the internet. New VPSes no longer ship that way.

Each new server is created with a candor user that has sudo, its own generated password, and your SSH key already installed if you gave us one when ordering. Direct SSH access as root is disabled as part of the first boot, so there is never a window where the server is reachable that way.

Root keeps its own password on purpose. If you ever lock yourself out of SSH, the console in your client area still gets you in — security should not mean losing access to your own machine.

The account to log in as, and its password, are on the service page under Information.

Picking a VPS used to mean dragging a slider through ninety-odd plans. Now the families are tabs and each one is a table: vCPUs, memory, disk and price in columns you can compare down the page. The Optimized family, which has the most options, splits further into General, CPU, Memory and Storage.

Choosing an operating system is a grid of distributions with their own logos — pick Ubuntu or Debian, then the version, instead of hunting through one long dropdown. Applications sit behind their own tab, sorted into categories with a filter box.

Anything that costs extra now says so before you click it, with the amount on the option itself: extra IPv4 addresses, block storage, and the Windows Server licence, which is charged per vCPU because that is how it is charged to us.

A deploy could build fine and then never come up — and sit there saying “deploying” until you gave up on it. Now we diagnose it and say so: the container exited immediately, or it crashed on startup, or it never became ready, with the exit code and the last lines of its output.

We also stopped requiring you to know your start command. We detect it from your project, tell you what we detected, and if we genuinely cannot work it out, we say that plainly rather than guessing and failing strangely.

Push to any branch other than the one your service tracks — or open a pull request — and Candor Deploy builds that commit at its own URL. Production is untouched. Pushing again updates the same URL, so a link you paste into a pull request keeps working.

Previews get your production environment variables except the ones you marked secret, which are never copied into a preview. Give previews their own values under Environment → Preview.

They clean themselves up: a preview disappears when its pull request closes, when its branch is deleted, or after seven days with no pushes. Your plan includes a set number at a time, shown on the Previews tab, and each one runs in 256 MB.

A Protection tab on every app and static site. Set a per-visitor request rate, or allow/deny specific IPs and ranges. Changes apply at our edge in seconds — no redeploy, no restart, no downtime.

Being straight about what this is: edge rate limiting and IP filtering. It is not a WAF, and we will not call it one. Blocked requests show up as 4xx on your Analytics tab so you can see it working.

Apps behind our edge were receiving an internal cluster address as the client IP rather than the visitor’s real one. Anything you built on the client address — rate limiting of your own, geo lookups, audit logs, abuse handling — was working from the wrong value.

Fixed at the edge with no downtime. Your app now sees the visitor’s actual IP, and so do the new rate limits and IP rules.

Add a cron schedule and a path, and we call that path in your app on time, every time. Run history and a run-now button are in the portal, so you can see what fired and when instead of guessing.

Requests carry a header secret so only we can trigger them, and they go to your app’s internal address — never through the public internet. How many you get is published on the tab, not discovered when one silently stops.

Logs were a wall of raw text. They now parse into rows with timestamps and levels, filter by level, search as you type, and live-tail. Structured JSON logs are unwrapped so you read the message, not the envelope.

Separately, a project can serve every one of its services under one domain, with each service answering on its own path. Your frontend and your API on the same origin, which is what most apps want and what removes a class of CORS problems entirely.