Managed, Without Being Locked Out.
SFTP, WP-CLI, a database manager and staging on every site. Your own container, your own Unix user, your own database, and a PHP version you choose.
Why Managed Hosting Annoys Developers
Three things that turn a ten-second job into a support ticket.
Managed Usually Means Locked Out
No shell, no database, a file manager that times out on anything larger than a theme. You end up raising a ticket to do something you could have done in ten seconds.
Everything Shares One Database User
On a lot of shared hosting every site on the account talks to the same database server with the same credentials, which makes isolation a polite fiction.
Nowhere Safe To Try Anything
Staging is sold as an upgrade, so changes get tested on production at eleven at night, which is how most WordPress outages actually happen.
The Access You Expect
SFTP And WP-CLI On Every Site
Key-based SFTP into the site’s own directory, and WP-CLI for the things the admin screen is bad at: search and replace, bulk plugin work, user fixes, cron inspection.
A Real Database Manager
Open a database session from the members area and browse tables, run queries, import and export. The session closes itself after an hour and nothing is left listening.
Staging, Then Push
Clone the site, work on the copy, push it back when it is right. On every plan, with a backup of production taken before the push.
PHP 8.3 And 8.4, Per Site
Choose the version per website and change it when you are ready, not when a shared pool gets upgraded underneath you. MySQL 8.4 behind it.
A Hidden Address To Work On
Every site has a temporary address from the moment it is created, and password protection if you want it. Dev sites are blank, protected WordPress installs that do not use a website slot.
A Container And A Unix User Each
Each site runs as its own user in its own container with its own database. File permissions mean something, and a neighbour cannot read your files.
Boring On Purpose
Google Cloud in Singapore. Nginx, PHP-FPM, MySQL 8.4 and Redis. Cloudflare at the edge. Every piece is something you have debugged before, which matters more at two in the morning than anything clever would.
The parts we built ourselves are the boring ones: provisioning, backups, isolation and the job queue that runs them.
See The Whole Stack
Start On Build
One site with the full toolset. Nothing here is gated to a higher plan.
Build
$240 a year. That is $48 less than paying monthly.
- One website
- 10 GB storage
- 50 GB bandwidth a month
- A temporary address to test on
Every Plan Has The Same Access
One website, properly hosted. For a business site, a portfolio or a blog that has to load fast and stay up.
- Servers In Singapore
- Free SSL On Every Domain
- Daily Backups, Kept 30 Days
- One-Click Staging
- Cloudflare CDN And DDoS Protection
- Nightly Malware Scans
- SFTP And WP-CLI
- PHP 8.3 And Redis
- Support From Real People
Every plan includes the same platform. The only difference is how many websites and how much room they have.
What Developers Ask First
Is there SSH?
There is SFTP with key authentication, and WP-CLI runs against your site. There is no general shell on the node. If you need root and a package manager, a VPS is the honest answer, and we would rather say so.
How do I connect to the database?
From the Database tab in the members area. It shows the host, port, database name and user, and the password is revealed on request. You can also open a browser-based manager session on the site’s own address, which expires after an hour.
Can I deploy from Git?
Not at the moment. Deploys are SFTP or WP-CLI today. Git deployment is built but switched off while we decide how it should behave with WordPress uploads, and we would rather ship it properly than half.
What is actually in front of the site?
Nginx with a page cache, PHP-FPM in the container, Redis for the object cache, MySQL 8.4 on a private instance, and Cloudflare at the edge. Nothing exotic, which is the point.
Can I turn the caching off while I work?
Clear it from the members area whenever you want, and the page cache stays out of the way for logged-in sessions. If you prefer your own caching plugin, the object cache is the part worth keeping, and the help centre explains how they interact.
What about cron?
WordPress cron runs from a real system cron rather than depending on traffic hitting the site, so scheduled posts and queued jobs fire whether anyone is visiting or not. You can see and manage the schedule for each site.
What You Will Not Find Here
Not A Fit
- Root access, cPanel or installing your own packages on the server. Use a VPS.
- Anything that is not WordPress. A Node or Laravel app has no home here.
- Git-based deployment, today. It exists in the platform but is switched off.
- Composer-managed WordPress with a custom build step. It can work over SFTP, but we do not run the build for you.
Try The Tooling On A Real Site
Create a site, pull it apart over SFTP and WP-CLI, break staging on purpose, and restore it. That is the whole evaluation.
Start On Build