The whole chain
in one place
Server, code, deployment, addresses, backups and team access — one panel that also tells you when something is wrong, one invoice, one place to call.
How it works
Six steps from an empty account to a running site that updates itself.
Create a project with a server
A project is what you build; a server is the hardware under it. One project can hold several servers — production, staging, database. The server is ready in under a minute.
Get a repository
The panel creates it on the built-in git server, opens access for the project team and sets up the webhook. Nothing to install, no third-party account to register.
Deploy it to the server
Pick a branch and a directory. The panel issues that machine its own read-only key, clones the code and prepares the server. One repository can go to several servers at once.
Push — and the site updates
Every push to the tracked branch builds a new release beside the running one and switches the site onto it at the end — a visitor never catches a half-updated site. main goes to production, develop to staging — same repository, same machine if you want.
Publish it at an address
The panel writes the web server config, points the domain and issues the certificate. Until you buy a domain, the site opens on the server IP — enough to show a client.
Keep it running
Backups on a schedule, snapshots before risky changes, a plan change in a minute when traffic grows, and security patches the server can install by itself. The project outlives any single server.
A project is shared from day one
Two ways in — start your own, or join one that already exists.
Start a project
You get the server, the repository and the deployment. Then invite the people you work with by email and give each of them a role: maintainer, developer or viewer.
- An invitation goes out by email
- The role decides what they can do with the code
- Remove someone — access disappears everywhere at once
Join an existing one
Follow the link from the invitation and the project is yours to work on: every repository, every server, every deployment — with the rights you were given. No separate git account, no keys to ask for.
- Access to the code is granted on the spot
- Nothing to set up on your side
- One account for every project you are in
This is what separates a project from a server. A server belongs to whoever pays for it; a project belongs to the people working on it — and they come and go without anyone re-issuing keys by hand.
Built for teams that serve clients
The difference shows up on the second project, not the first.
Access you can take back
Membership in a project is the right to the code. Add a developer — they see every repository of that project. Remove them — access disappears everywhere at once, no forgotten keys left on machines.
Staging next to production
Two branches of one repository on one machine, each with its own directory and address. Check the layout before the client does — without paying for a second server.
One invoice, one responsibility
Control panels rent you software and leave the hardware to someone else. We own the hardware: if a server goes down, there is one place to ask, and it is us.
Your server stays yours
Full root access, your own OS, your own tools. Everything the panel does — systemd, git, ssh — you can do by hand. The panel is a convenience, not a lock.
It keeps an eye on things
Deploying is the easy half. The other half is noticing when something goes wrong.
Alerts before it hurts
Disk filling up, memory running out, a machine that stopped answering, a site that no longer opens from outside — checked every five minutes. You get one email per problem, not a stream of reminders, and it closes itself when the cause is gone.
Logs without SSH
Web server errors, system journal and your application log — readable from the panel. That is usually the difference between finding the cause in a minute and opening a terminal to hunt for it.
Roll back a bad deploy
Every deployment is recorded with its commit, and the built release is kept on the server. Pick an earlier one and the site is back on it in a moment — nothing is fetched and nothing is rebuilt. Your repository history stays untouched: the fix belongs in the code, not in rewritten branches.
State, not a menu
The project page shows what needs attention before it shows what you can click. If everything is fine, there is nothing to read.
This is what a DevOps engineer does on an ordinary day: watch, look into the logs, roll back when needed. Not all of it — but the part you would otherwise be paying for every month.
Or just take a server
Everything above is optional. Nothing forces you into it.
A bare server, no questions asked
Pick a size and an OS, get root access in under a minute, and do whatever you do. No repository, no deployment, no project — a plain VPS, billed by the hour.
Bring a site you already have
Copy the files and the database across by hand, the way you always have. The server does not care how the code got there — backups, snapshots, certificates and plan changes work the same.
Add the rest later, or never
Wrap the server into a project when you need a teammate on it. Connect a repository when you get tired of uploading by hand. If that day never comes, nothing breaks.
A migrated site can be adopted
Point a repository at a directory that already has your site in it and we connect it in place — without deleting anything. Files that are not in the repository stay where they are.
This is not a platform you move into. It is a server you own, with tools you switch on one at a time.
What this is not
So that nothing here comes as a surprise later.
Not a website builder
There are no templates and no drag-and-drop. This is for people who write code and need somewhere to run it.
Not a replacement for your editor
Work in the IDE you already use. We take the code from the repository — what you write it in is your business.
The database is yours
We do not run it for you: no managed database, no separate replica, no tuning. A copy of the server includes it whole, and a restore brings it back whole — but between those two moments the database is your business.
What it runs on
AMD Ryzen processors, NVMe drives, KVM isolation and hourly billing — the same hardware as our VPS hosting, because the platform is not a separate product. It is what that hardware is for.
Plans
Hourly billing: stop the server and billing stops with it. The plan changes in a minute, so start small.
- 2 vCPU AMD Ryzen
- 4.0 GB RAM
- 50 GB NVMe
- 4 vCPU AMD Ryzen
- 8.0 GB RAM
- 80 GB NVMe
- 6 vCPU AMD Ryzen
- 12.0 GB RAM
- 100 GB NVMe
- 8 vCPU AMD Ryzen
- 16.0 GB RAM
- 120 GB NVMe
Frequently asked questions
What people ask before starting.
Start with one project
A server in under a minute, a repository in one click, and hourly billing — stop the server and billing stops with it.