What unique features would you like to see from a VPS provider?

• All essential features should work with JavaScript disabled.
• Registration should not ask any information (no password, nothing, ...) like Mullvad, IVPN, etc... it should just give you a server-generated secret used for login. The client can update the settings later if they want to.
• Hourly billing. It is nice to test different VPS configurations without subscribing for a whole month.
• Add PGP key to contact page.
• No logs, or temporary logs deleted after X days (like 14d), never stored forever.
• Soft bandwidth limit instead of a hard limit. The limit should only be enforced if other clients are negatively affected. Maybe it could be an exclusive perk to long-time clients (like active subscription over 3 months).

@Rhea We actually do a few of these already, but I think we will most likely implement some of the others in future.

• I plan to offer a CLI tool in addition to a minimal control panel with no JS for slow connections.
• We're already doing this, you get a token, you log in with that token and your password.
• I'll think about this, I think the option for just billing by day is easier (if a user isn't happy, they can get a prorated refund instantly), but if I did allow hourly billing, it would have to require a deposit to kerb abuse. I'm already considering requiring a deposit because the cheap plans get abused a lot. The hourly rate would also need to be higher than the monthly rate to compensate for the churn.
• I should add that now, there's no reason not to. Though I generally prefer that users contact us over matrix.
• We don't log anywhere I'm aware of and don't need to log, so that's already done.
• And we do this too, when you hit the traffic TB cap, you get a 10 megabit speed cap. Other clients wouldn't be affected by "unmetered" bandwidth, however bandwidth isn't cheap so we couldn't give it away for completely free. I do want to relax the default speed caps in future as well.

@Kodomu Really good response, thanks.

I really like the token, but token + password is a bit weird I think. It would be perfect if registration was just a one-click button that gives you only a token and you configure the rest later (if you want).

Another suggestion: offer ability to buy DDOS-protection service.

@Rhea We ask for the password because it's not like a VPN where there's no personal data at stake, the token is essentially treated as a generated username, it's not considered "private".
We mostly use it so that people can't check if your email is signed up, in fact, more than one account can share the same email since there's no code to check if it's unique, we just use it to send notifications and password resets.

The registration is pretty much providing a password, selecting a language that you want the tickets to come in (we have multiple supported languages), and then you get the generated token to log in with. I think it's a pretty simple flow compared to most others. You can optionally provide your matrix username for encrypted communication too.

We already have basic DDOS protection, I do want to add a higher tier in future though but we try to avoid reliance on third party services where possible.

Seconding the no-JS mentioned above.
Also, some non-SystemD image options (idk whether you already have those). eg.: Devuan, Artix.

@Kodomu I don't recommend releasing a standalone CLI tool — you're unlikely to do it well. Users who need non-web access often have high security/KISS requirements: if your standalone tool is only a few hundred lines it's fine, but most VPS providers' tools are bloated and even require pip installs, which pro-users won't accept, and less picky users won't use a CLI at all.

My recommendation: use SSH for user registration. Every CLI user already knows SSH; it avoids running remote code locally, which is much safer for end users; and it's easy for you to implement — use SSH exec to keep the client-side logic on the server for account registration and machine management (like slowservers does).

a tutorial section for people less technically inclined but who value privacy that gives some really simple examples, maybe templates, on 'use cases for a vps, how to begin a blog using our vps, how to set up a community server for (x platform) using our vps)

Are those use cases for vps-es? hopefully, otherwise I'll look silly...

ip addresses that are not blocked for being suspicious.

As an aside, connecting from a VPS to ticketmaster.com is a good test website to see if the VPS ip is suspicious. Ticketmaster blocks everyone it seems.

Registration should be possible with PGP and no other mandatory data.

Login via PGP challenge.

Best case: No logins at all - just stateless PGP interactions, as the god of the internet intended :)

Idea: Make it ai-agent-friendly.

@ancap_objectivist We've got Alpine with OpenRC if that counts :)

@armed The CLI tool will mostly be a wrapper for API calls that we will already be allowing.

@ksilverstein I can't promise anything like that, as generally IPs marked as "datacentre use" are treated differently to ones marked for residential connections, but it will be better than any public or commercial VPN, that I can promise.

@Otherfren I thought about it, but there's too much friction for the average user, and I think using what's essentially a generated username without requiring email is a good balance. We will have an API in the future for automated creation, configuration and destroy of services.

@avarice Definitely in the future.