Everything the console does, grouped six ways.
One platform, not a catalogue of services to assemble. Four of these families have a page of their own and this one hands off to it; Operations and Developer live here, in full, because there is nowhere else they belong.
Compute
vCPU, memory and SSD sized independently, resized live with a quote first.
Open the Compute page →Storage
Local NVMe, volumes that grow, snapshots and S3-compatible buckets.
Open the Storage page →Networking
An isolated network and a virtual router per account, with NAT you control.
Open the Networking page →Operations
Metrics with a known age, threshold alerts, power schedules and an activity log.
On this page ↓Developer
SSH keys, cloud-init, one-click stacks and a REST endpoint for every action.
On this page ↓GPU
Not in the catalogue yet — and that page says so rather than taking a deposit.
Open the GPU page →Three quantities, and no tier to be upsold into.
You choose vCPU, memory and SSD independently, inside two ratio rules, and the price is those three numbers multiplied out. A running instance can be resized, and you see the quote before you commit to it.
Shape
- 1–64 vCPU, metered per core per month
- 1–512 GB memory, metered per GB
- 10–16,384 GB NVMe SSD, metered per GB
- 1–16 GB of RAM per core
- 1–50 GB of SSD per GB of RAM
- Live resize with a quote first
Lifecycle
- Deploy in about 58 seconds
- Rebuild in place from a template
- Recycle bin with restore
- Expunge with the disks when you mean it
- Scheduled reboot, stop and start
- Root on the machine, always
Billing
- Committed monthly or on-demand hourly
- Hourly is (monthly × 1.2) ÷ 730
- A month never bills past 120 %
- Renewal anchored to the 5th
- First period prorated per day
- Downgrades credited to the wallet
The spec table, the two ratio rules and what a resize actually does to a running machine: the Compute page →
A disk that grows, and copies that are not the same thing as backups.
The root disk is local NVMe on the instance’s own hypervisor. Volumes live independently of any instance, snapshots are taken in seconds, and object storage is an S3 endpoint your existing client already speaks to.
Volumes
- Created independently of an instance
- Attached, grown, detached, deleted
- Priced with a quote before creation
- Moved between instances
- Cut fresh from a snapshot
- Rate quoted rather than published
Snapshots and backup
- Point-in-time copies on demand
- Volume and whole-instance snapshots
- Revert a volume onto a snapshot
- Backup add-on: daily, 7 rolling restore points
- 20 % of the instance price per month
- Opt-in, and removable
Object storage
- S3-compatible buckets
- Per-bucket access key and secret
- Short-lived signed URLs per operation
- Any S3 client you already use
- Object data never crosses our API
- API today — no console screen yet
There is no egress metering and no bandwidth allowance to exceed, on any of it. The Storage page →
Accounts share hypervisors. Accounts never share a network.
Your first instance brings up an isolated network with a virtual router in front of it, and every instance after that joins the same one. Nothing to design, nothing to request, and no route another account can take into it.
Included with the account
- An isolated network per account
- A dedicated virtual router
- Source-NAT public IPv4
- Private addresses on your own range
- Port forwarding — free, any number
- Firewall rules applied without a ticket
Paid additions
- Dedicated IPv4 with static NAT
- Load balancer, health-checked
- Remote-access VPN
- Flat monthly rates, GST inside
- Removable, with the unused part credited back
Over the API
- VPC with tiers and per-tier ACLs
- Asynchronous VPC creation
- Firewall and forwarding rules as resources
- A routed VPC type loses forwarding, NAT, LB and VPN
- One Indian zone, and no cross-region hop
The console draws your network and a neighbour’s side by side, because hiding the neighbour would prove nothing. The Networking page →
Numbers with a known age, and alerts that reach something.
A console that shows you a stale figure is worse than one that shows you nothing, because you act on it. Every number below carries how old it is, and the rules you set on those numbers deliver somewhere you are actually watching.
Metrics you can date
CPU, memory, disk and network sampled every 60 seconds and kept for fourteen days. Power state is polled separately, every 45 seconds, because a machine being on is a different question from how busy it is.
Threshold rules, not a dashboard to stare at
Set a rule on an instance metric — CPU above 80 % for ten minutes — and it notifies by email or by a signed webhook, with a delivery log and a retry on the failures.
Power on a schedule
Reboot, stop and start on a cron expression in your own timezone, with the next few firings returned so you can see what you actually asked for before it happens at 3am.
A per-instance activity log
What changed on this machine, when, and who asked for it — on the instance itself rather than in one account-wide stream you have to filter down.
Tickets pinned to the machine
Open a ticket against a specific instance, from the console or over the API, so an alert in your own monitoring can open one in ours. P1 is acknowledged in one hour, 24×7.
Webhooks on state change
Signed webhooks fire when an instance changes state, with a delivery log and a retry you can trigger by hand or by rule — so your own systems hear about it without polling us.
What happens in the first minute.
Six stages, timed on the platform rather than rounded for a headline. There is no queue in front of them and no capacity request to file first.
You submit a shape Three numbers and an image. The wallet is debited for the prorated first period, not a whole month.
Sampling
- CPU, memory, disk and network every 60s
- 14 days of retained history
- Power state polled every 45s
- Current and historical, over the API
Alerting
- Threshold rules on instance metrics
- Email or signed webhook
- The events a rule has raised, kept
- Delivery log, with retry
Control
- Scheduled reboot, stop and start
- Cron expressions in your timezone
- Per-instance activity log
- Tickets pinned to one instance
Root from the first minute, and an endpoint for everything after it.
Your keys go on at create time and your cloud-init runs once on first boot. After that, every action the console can take has a REST endpoint behind it — the console is a client of the same API you get.
SSH keys at create time
Keys stored on the account are injected when the instance is built. Import a pair you already have or generate one here — either way you hold root on the box from the first boot.
Arbitrary cloud-init
Paste any user-data script and it runs once, on first boot, and is then over. A marketplace stack is that same mechanism with the script already written — readable, and replaceable with your own.
Your own images
A shared ISO library plus your own uploads, and a rebuild-in-place from a template when you would rather start the machine over than build a new one.
A REST endpoint for every console action
Deploy, quote, resize, rebuild, power, volumes, snapshots, networking, buckets, alerts and tickets. Long operations return 202 and a task handle rather than holding the connection open.
Keys you can scope and revoke
API keys can be pinned to a single instance, state-changing calls take an Idempotency-Key so a retry cannot double-charge you, and there is an account-wide kill switch for the API.
A spec nobody types
The OpenAPI document is generated from the routes themselves, so it cannot drift from the API it describes. There is a dependency-free TypeScript SDK if you would rather not write the curl.
The endpoint list, the auth model and the webhook contract: API & integration → · fifteen stacks that are cloud-init and nothing more: the Marketplace →
Being brought online through 2026 — and not sold before it is.
There is no GPU instance type in the catalogue, no accelerator field in the console and no GPU term in the price formula. We would rather say that here than take a reservation for it.
Live today
- vCPU, memory and SSD sized independently
- Live resize without rebuilding
- Snapshots on demand
- One Indian zone, billed in rupees with GST inside
Not yet
- No GPU instance type
- No accelerator field in the console
- No GPU term in the price formula
- No GPU image or driver template
- No reservation, deposit or early-bird rate
The full position, including what would have to be true before it ships: the GPU page →
What people ask after reading the list.
Is any of this held back for a higher tier?
No. There are no tiers to be held back by — you size vCPU, memory and SSD yourself and the price is those three numbers multiplied out. The paid additions are the ones named as paid on the networking and storage lists: a dedicated IPv4, a load balancer, a VPN and the backup add-on.
Why do Operations and Developer not have their own pages?
Because they are capabilities of the platform rather than things you buy separately, and the material is small enough to read in one sitting. It is documented here in full rather than scattered across the compute and API pages, which is where it used to live.
Can I drive all of this from the API?
Every action the console can take has a REST endpoint behind it, including the ones with no console screen yet — object storage, additional volumes and VPCs are reachable over the API today. The API page is the honest list of what exists.
What is not here?
Managed databases, managed Kubernetes and a GPU instance type. None of them are in the catalogue, none of them are in the price formula, and none of them appear anywhere on this site as though they were.
Start with Comsky Cloud.
Grow into the ecosystem.
One account opens every Comsky product — and one invoice covers them, however many you run.