One click to install it. Then it is just your machine.
Pick a stack at deploy time and cloud-init installs it during the first boot. When that boot finishes, the script is done forever and what you are left with is an ordinary Ubuntu instance with your SSH key on it. No control plane between you and the box, no console-only settings, and no hatch you cannot open. Stacks cost nothing extra — you pay for the vCPU, memory and SSD the formula prices, and that is the whole bill.
Fifteen, because fifteen is what the catalogue carries. Project names are their owners’ trademarks and appear here to say what gets installed, not to claim any endorsement.
Four layers, and you administer three of them.
This is the whole argument. A managed catalogue sells you a running thing and keeps the keys; a marketplace entry hands you a running thing and walks away. Here is exactly where the line sits, layer by layer.
Your application
Whatever you put on the box after first boot. We never see it, never patch it and never restart it. No agent of ours is watching it.
The cloud-init payload
The script the marketplace entry runs once, on the first boot, to install the stack. You can read it, replace it, or paste your own instead — the catalogue is a shortcut through this layer, not a gate in front of it.
The OS image
Ubuntu 24.04 LTS, kept current as a template. From the moment it boots, the package manager is yours: you choose when to upgrade, and we do not hold a key to it.
The instance
The virtual machine, its volume, its network and its power state. This is the layer we operate, meter and are accountable for. It is the only one.
Read it upwards and the claim is testable: if you can ssh in, become root, change the config and restart the service without opening our console, then layers one to three really are yours. They are.
A script that runs once, and then is over.
No daemon we installed keeps phoning home. No package is pinned so you cannot upgrade it. Nothing reverts your changes on the next reboot, because there is nothing left running that could.
It runs on the first boot only
cloud-init executes the payload once, while the machine is coming up for the very first time. Reboot the instance afterwards and nothing re-runs. Edit a config file the script wrote and it stays edited — there is no reconciliation loop to fight with.
You hold root from the first minute
Your SSH key goes on at create time. There is no vendor account on the box, no support back door and no console-only setting that the shell cannot also reach. If you lock yourself out, that is a snapshot restore, not a support escalation.
Upgrades are yours to schedule
The package manager is untouched and the repositories are the distribution’s own. Upgrade the stack when it suits you, or pin it where it is. We do not push a version at you and we cannot, because we are not holding a control plane over it.
A stack is not a plan
Choosing Docker or PostgreSQL does not put you on a different product, a different rate or a different support tier. The instance is priced by the same three rates either way, and you can install a second stack by hand an hour later.
The payload is readable
A marketplace entry is a cloud-init recipe, not a black-box image. Ask us for the one behind any stack and we will show it to you — and then you can paste your own version instead if you would rather change a line.
It lands on your own network
The instance joins the isolated network your account already owns, behind your own virtual router, with a source-NAT public address included. What the stack listens on is what you decided to forward, which is nothing until you say so.
The marketplace is a shortcut, not a gate.
Everything the catalogue does at deploy time, you can also do yourself at deploy time. If your stack is not on the list, that is a reason to paste a script — not a reason to pick a different provider.
Your own cloud-init
Paste any user-data at create time and it runs instead of, or alongside, a catalogue entry. This is the same mechanism the marketplace uses — there is no privileged path reserved for our own recipes.
Your own ISO
Upload an image to the ISO library and boot an instance from it. That is how you run an operating system Comsky does not ship as a template, rather than waiting for us to add one.
Your own keys
Import an existing public key or have the account generate a pair. Keys are stored on the account and injected at create time, so a new instance is reachable the moment it finishes booting.
All fifteen, grouped the way the console groups them.
Containers & runtime
- Docker — engine and compose plugin
- Portainer — a UI over the same engine
- Node.js — LTS runtime and a process manager
Databases
- PostgreSQL
- MariaDB
- MongoDB
- Redis — cache, sessions and queues
Web & frameworks
- Nginx — reverse proxy and static server
- Django — Python, framework and WSGI server
- Ghost — publishing, with its database
DevOps & CI/CD
- GitLab CE — repositories, issues and CI
- Jenkins — controller and service
Observability & files
- Grafana — dashboards on your own box
- Nextcloud — file sync and share on your SSD
Collaboration
- Rocket.Chat — team chat you host yourself
- And anything else, via your own cloud-init
Size the instance for the stack, not the other way round. Multiply out a shape on the pricing page →
About the marketplace specifically.
Do the stacks cost extra?
No. A marketplace entry is cloud-init, and cloud-init is free. You pay the same vCPU, memory and SSD rates you would pay for an empty instance — the same per-unit monthly rates, GST already inside. There is no per-stack line on any invoice.
Is this a managed service?
No, and that is the point. We run the instance, its volume, its network and its power state. The operating system and everything above it is yours from the first boot. Nobody from Comsky logs into your box, and no agent of ours manages the stack. If you want hands-on operations, that is the separate managed-service add-on, bought deliberately.
Can I install a second stack afterwards?
Yes — the same way you would on any Ubuntu machine. apt install is not disabled, the repositories are the distribution’s own, and nothing reverts your changes. Most people pick Docker at deploy time and then run whatever they like inside it.
What if the stack I need is not one of the fifteen?
Paste your own cloud-init at create time and it runs verbatim, or boot from your own ISO out of the library. The catalogue is a convenience for the fifteen most-asked-for; it is not the boundary of what you can run.
Which operating systems can I choose?
Ubuntu 24.04 LTS is the customer-selectable template today, and every marketplace entry installs onto it. Anything else arrives through the ISO library, where you can upload your own image and install from it.
Can I see what a stack actually does before I pick it?
Ask and we will show you the cloud-init behind it. It is a script, not a sealed image, and there is nothing in it we would rather you did not read.
What happens if the install script fails?
You get a plain Ubuntu instance you can log into and fix, because the failure is confined to the payload — the machine itself is already provisioned and already yours. Take a snapshot before a risky change and you can also simply roll back.
Do you patch the stack for me?
No. Upgrades are yours to schedule, which is the same sentence as “we cannot break your production on a Tuesday”. Monitoring is included on every instance if you want to watch it; patching only happens if you buy the managed-service add-on.
Start with Comsky Cloud.
Grow into the ecosystem.
One account opens every Comsky product — and one invoice covers them, however many you run.