Most first-time colocation buyers either over-commit and pay for empty cabinets for two years, or under-commit and discover at month nine that the contiguous cabinets they need for expansion have been sold to someone else. Both mistakes come from the same root cause: treating capacity planning as a procurement exercise rather than an engineering one.
This guide is for organisations buying their first significant colocation footprint — whether to retire an on-premise room, scale a growing application, or land regional infrastructure in Indonesia for the first time. The framework below is deliberately conservative on assumptions and specific on the questions that should drive a final commitment.
What “Capacity” Actually Means
A common reason first buyers under-specify is treating capacity as floor space. Modern data centers price and constrain almost exclusively on power and cooling, not square metres.
A useful capacity inventory has four layers:
- Power. Energised kilowatts the operator can deliver to your cabinets, today, with redundancy. Contracted megawatts that are not yet energised are not capacity you can use.
- Cooling. Whether the row supports the density you intend to deploy. A facility rated for 6 kW per cabinet average can host 15 kW cabinets only in specific rows with adequate airflow or rear-door heat exchangers.
- Network. Cross-connect inventory, on-ramp diversity, and access to internet exchanges. Capacity without connectivity is a warehouse with servers.
- Adjacency. Whether the operator can give you contiguous cabinets when you expand. A single cabinet purchased in isolation may sit next to a competitor’s cage with no migration path.
If any one of these layers is constrained, the others do not matter.
A Four-Step Planning Framework
The same framework works for ten cabinets or a megawatt. The numbers scale; the order does not.
Step 1: Forecast the workload, not the rack count. Start from the application: how much compute, how much storage, what redundancy. Translate that into nameplate power. Apply a realistic utilisation factor — most workloads draw 40 to 70 per cent of nameplate. Add a growth multiplier over the contract term, then a safety buffer.
Step 2: Translate demand into power before counting cabinets. A 100 kW deployment fits in ten 10 kW cabinets, six 17 kW cabinets, or three 33 kW high-density cabinets. The right answer depends on the workload’s density profile, the operator’s row design, and your network requirements. Cabinet count is an output of this calculation, not an input.
Step 3: Choose a commit profile. Most operators offer a committed-plus-burst structure. The committed portion locks price and capacity for the term; burst capacity is available at a premium when you exceed commit. First buyers tend to over-commit when burst would have served them better, and under-commit when steady growth would have justified a larger floor. The right ratio depends on how confident the forecast is — high-confidence steady-state workloads should commit deeper; volatile workloads should commit narrower and burst wider.
Step 4: Buy expansion rights, not just capacity. A two-year contract for ten cabinets is worth less than a two-year contract for ten cabinets with right of first refusal on the adjacent row. The single most expensive failure mode in first deployments is needing to expand and being unable to do so contiguously. Negotiate this in the original contract, not at renewal.
Planning Capacity When You Are New to Indonesia
For organisations landing Indonesia infrastructure for the first time — typically global SaaS, OTT, gaming, or fintech businesses serving Indonesian users from Singapore or further afield — the planning framework above still applies, but three additional questions usually decide the shape of the footprint.
The first is regulatory. Indonesia’s Personal Data Protection Law and the PSE registration regime push more workloads onshore than international teams typically expect. A capacity plan built on the assumption that Indonesian traffic can continue to be served from Singapore is often a plan that has not yet been read by legal.
The second is connectivity. Indonesian end users are concentrated in a small number of large eyeball networks. Serving them efficiently means peering at a domestic internet exchange inside Jakarta, not buying transit in Singapore. The capacity decision and the peering decision are the same decision; sequencing them separately produces deployments that perform worse than the previous offshore arrangement.
The third is footprint discipline. The most common mistake foreign operators make is deploying too small to be useful — a single cabinet that does not justify the cross-connects, peering, and operational overhead. The minimum viable Indonesia footprint is usually larger than a first-pass capacity plan suggests, and the right benchmark is whether the deployment can support local origin serving plus a CDN cache layer with headroom.
Capacity Planning for AI Workloads
Conventional enterprise workloads still fit comfortably in 5 to 10 kW cabinets. AI training and inference do not. A single eight-GPU server with current-generation accelerators draws 10 to 14 kW on its own; densely packed training rows now run at 50 to 100 kW per cabinet, with liquid-cooled deployments reaching higher still. The hardware profile inside an AI-ready data center is fundamentally different from a conventional enterprise hall.
This changes the planning calculus in three ways.
Cabinet count becomes almost irrelevant. A 1 MW AI deployment may occupy fewer than fifteen cabinets. The constraint is power, cooling, and the row’s structural readiness, not floor space.
Cooling readiness is a binary gate, not a parameter to tune. A row designed for 8 kW air-cooled cabinets cannot host 60 kW liquid-cooled racks regardless of contractual provisions. Confirm the specific row, the manifold availability, and the operator’s liquid cooling roadmap before committing.
Power headroom matters more than total contracted capacity. Training workloads have transient draws that exceed steady-state significantly. A deployment that fits within contracted capacity at steady state can trip protection at peak. Operators with conservative power topology and ample headroom are worth a price premium for AI workloads.
The IEA’s Electricity 2024 report flags data center power consumption — driven primarily by AI — as one of the fastest-growing electricity demand categories globally. Capacity plans written without an AI density assumption built into the contract are routinely outdated within twelve months.
Questions to Ask Before Signing
The questions that protect a first-time buyer are uncomfortable to ask, which is why most first deployments do not get asked them.
- How many megawatts of energised capacity does the facility have today, and what is the substation status for the next phase?
- What is the cabinet density cap per row, and which rows are liquid-cooling-ready?
- What are the right-of-first-refusal terms for adjacent cabinets and adjacent rows?
- How many cross-connects are included in the base contract, and what is the per-cross-connect cost beyond that?
- What is the remote-hands SLA in hours, and what is the after-hours premium?
The answers to these questions, written into the contract, are usually worth more than the headline price per kilowatt.
Conclusion
Capacity planning is the part of a colocation engagement where most of the long-term cost — and most of the operational pain — is determined. First-time buyers who treat it as an engineering question rather than a procurement exercise tend to land deployments that scale cleanly through the contract term. Buyers who treat it as procurement tend to discover the cost of that decision around month nine, when expansion plans collide with adjacency they did not negotiate.
If your organisation is planning its first Indonesia colocation footprint or sizing an AI-ready deployment, speak with the Digital Edge Indonesia team about energised capacity and contiguous expansion across EDGE1, EDGE2, and the CGK Campus.
