Modular Data Center Guide: Design, Types, Cost and Deployment

Originally published May 3, 2026. Updated September 19, 2026 with current ModulEdge product configurations, a buyer input checklist, a worked selection example, and revised supplier-evaluation guidance.

A modular data center is a complete data center—or a defined power, cooling, or IT block—that is engineered, integrated, and tested in a factory before installation on site. It may be a compact edge facility, a containerized data center, a prefabricated modular building, or a repeatable block within a multi-megawatt campus. Its defining feature is not the enclosure. It is the decision to move integration and testing from the construction site into a controlled manufacturing environment.

This guide covers the main modular data center types, the systems inside them, the information a buyer needs before requesting a proposal, and the factors that determine cost, schedule, rack density, and cooling. It also explains how to compare suppliers whose quoted scopes may look similar but include very different work.

For a first shortlist: define the initial and ultimate IT load, list every rack and its peak power, confirm the site utility and cooling interfaces, set the availability objective, and assign the external scope. Then compare platforms against those inputs and request evidence for the proposed configuration.

What is a modular data center?

A modular data center is pre-engineered around a defined IT load, rack population, cooling method, availability objective, and set of site interfaces. Power distribution, cooling, racks, fire protection, monitoring, security, and controls are assembled as coordinated systems before delivery. Factory acceptance testing verifies the agreed factory scope. Site acceptance and integrated testing then verify the completed installation.

Three related terms are often used as if they mean the same thing:

• Modular describes an architecture built from repeatable units or subsystems.
• Prefabricated describes the manufacturing method: assemblies are built and integrated away from the final site.
• Containerized describes one transportable form factor. A modular data center does not have to use a shipping container.

A container can suit a remote or mobile deployment. A prefabricated modular building may provide better rack geometry, access, and maintainability for a high-density AI installation. The right choice follows the workload and site. Our modular, prefabricated, and containerized data center comparison examines those procurement differences in more detail.

Modular data center types and where they fit

Start with the IT equipment, rack dimensions and densities, network topology, maintenance model, site constraints, and planned growth. Select the module geometry only after those requirements are understood.

What to define before requesting a proposal

A supplier can provide a credible configuration only when the input brief describes the load and the site. A one-line request for “a 1 MW modular data center” leaves unanswered whether 1 MW means usable IT capacity, utility input, or a rounded project label.

The US General Services Administration and Lawrence Berkeley National Laboratory make the same point in their modular data center procurement guide: buyers should define rack space, present and future IT power, equipment details, inlet and exhaust conditions, airflow, and rack power connections before engaging suppliers. A short but precise input schedule saves more time than a long specification built on unclear capacity terms.

What is included in a modular data center?

A complete modular data center coordinates several engineering systems. Contract boundaries vary, so compare what is included rather than comparing product names alone.

Power architecture

The power train may include utility or generator inputs, transformers, MV and LV switchgear, transfer equipment, UPS systems, batteries, PDUs, busway, rack PDUs, grounding, metering, and controls. Availability must be assessed across the system. An N+1 component count does not, by itself, create an end-to-end concurrently maintainable design. Our power architecture and redundancy guide explains N, N+1, distributed redundancy, and 2N.

Cooling and heat rejection

Cooling may use precision air conditioning, free cooling, chilled water, rear-door heat exchangers, direct-to-chip liquid cooling, or a hybrid architecture. The design must follow the complete heat path: from the IT equipment to the room air or liquid loop, through pumps or cooling distribution units, and finally to outdoor heat rejection. A label such as “liquid cooled” is incomplete without temperatures, flow, pressure, ambient design conditions, controls, and redundancy.

For a closer comparison, see our guides to free cooling, DX, and hybrid cooling and liquid cooling in data centers.

IT space and connectivity

The IT zone includes racks, containment, cable routes, fiber and copper distribution, equipment access, lighting, and maintenance clearances. At high density, rack depth and width, door swing, overhead busway, liquid manifolds, service corridors, and floor loading have to be coordinated before fabrication.

Fire protection, security, and controls

Detection, suppression, access control, CCTV, leak detection, environmental sensors, BMS, EPMS, and DCIM have to operate as a coordinated system. Fire and building requirements remain specific to the project and jurisdiction. Factory integration reduces interface risk; it does not remove local permitting, site acceptance, or the operator’s compliance obligations.

Site and external interfaces

The project must assign responsibility for foundations, drainage, transport and lifting routes, incoming power, fuel systems, external heat rejection, communications, water where required, and final connections. An undefined interface can delay a project even when the factory-built modules are complete.

Four capacity numbers buyers should not confuse

Capacity figures become misleading when their measurement boundary is omitted. Keep these four numbers separate in the brief, proposal, and acceptance documents.

The relationship is physical: almost all electrical power consumed by IT equipment eventually becomes heat. The facility must also supply and cool supporting equipment. A proposal should therefore state the IT boundary, facility input basis, rack-by-rack load schedule, and design conditions used for the cooling calculation.

How modular data center design works

A reliable design begins with requirements, not a catalogue image:

1. Define the workload and IT equipment. Record rack count and dimensions, nominal and peak IT load, airflow or liquid requirements, network racks, cabling, and expected technology refresh.
2. Confirm the site. Establish utility capacity, power quality, climate, altitude, dust or humidity exposure, geotechnical conditions, transport access, noise boundaries, water availability, and permitting constraints.
3. Set the availability objective. Translate operational requirements into power paths, cooling redundancy, maintenance strategy, battery autonomy, standby generation, and fault domains.
4. Select the thermal architecture. Match rack density and equipment interfaces to air, rear-door, direct-liquid, or hybrid cooling and to the outdoor heat-rejection plant.
5. Freeze module and site interfaces. Define what is completed in the factory, what is installed on site, and who owns every connection and test.
6. Plan FAT, SAT, and integrated testing. State the loads, failure conditions, control sequences, witnesses, and acceptance evidence for each stage.

A modular platform is repeatable, but the final configuration still has to match the load, site, operating model, and local requirements.

Worked example: from an 80 kW requirement to a first shortlist

This is an illustrative requirements exercise, not a quotation or a guaranteed configuration. Consider an enterprise buyer with an existing European industrial site, nine planned server racks, one network cabinet, and an 80 kW design IT load. The equipment is air cooled, most racks remain below 10 kW, and the buyer wants N+1 power and cooling with short-duration UPS autonomy.

Type M would enter the shortlist because its documented baseline is 80 kW, nine server racks, one telecom cabinet, N+1 power and cooling, and 15-minute UPS autonomy at full IT load. It would not be selected from IT load alone. The supplier still needs the rack-by-rack peaks, ambient conditions, power quality, generator strategy, physical route, fire requirements, and exact contract boundary.

At this stage, the connection check is a boundary equation rather than a guessed percentage: required site input equals the 80 kW design IT load plus cooling demand, electrical losses, controls and other auxiliaries, non-IT loads inside the agreed boundary, and operating margin. The selected equipment, climate and operating conditions determine those additions.

The same discipline applies to cost and schedule. Compare the installed scope—not only the module price—and measure the program from requirements approval through operational handover. A factory completion date is not an in-service date if the site connection, external plant, permits, or acceptance testing remain incomplete.

Modular data center vs traditional construction

Modular construction usually fits projects where time-to-power matters, demand will grow in phases, several similar sites are planned, the site is difficult to build on, or rack density requires a purpose-engineered thermal system. Traditional construction may suit a one-off campus with stable long-term demand, a flexible schedule, and a strong local construction ecosystem. Large projects often combine both: site-specific civil works with prefabricated power, cooling, and IT blocks.

What determines modular data center cost?

There is no universal price per rack or per megawatt. Modular data center cost depends on the installed scope and site conditions. The main cost drivers include:

• IT load, rack density, and rack population;
• power topology, UPS autonomy, and standby generation;
• air, rear-door, direct-liquid, or hybrid cooling;
• climate and environmental hardening;
• fire-protection and regulatory requirements;
• transport, lifting, foundations, and site utilities;
• factory, site, and integrated testing;
• local labor, taxes, customs, and component availability;
• service, spares, warranty, and operations scope.

Normalize the boundary before comparing quotations. One price may include external chillers, generators, transformers, foundations, commissioning, and controls integration; another may stop at the module wall. The lower module price can become the higher installed-project price once missing interfaces are added.

Phasing is a separate financial decision. A modular design can defer part of the capital program until demand exists, but the result depends on utilization, financing, the expansion sequence, and which shared systems must be sized for later phases. Our modular data center cost guide provides a fuller comparison framework.

How long does modular data center deployment take?

Any quoted schedule should define its start and finish. “Delivery time” might mean order to factory shipment, shipment to site installation, or the complete program through commissioning. Those are different dates.

Factory production can run in parallel with foundations, utility work, and site preparation. The complete program still depends on design approval, long-lead electrical and cooling equipment, permits, grid availability, transport, crane access, site readiness, commissioning, and acceptance testing. A completed module cannot provide usable capacity if the site or power connection is late.

Ask for a dependency-based program covering:

• design freeze and approval;
• long-lead equipment release;
• factory assembly and FAT;
• site works and utility milestones;
• transport, lifting, and connection;
• SAT, integrated testing, and handover.

Rack density and cooling selection

Rack density quickly eliminates unsuitable designs. Across its portfolio, ModulEdge supports projects from 5 to 150 kW per rack. That range spans several products and cooling methods; it is not a universal rating for every configuration.

Lower-density enterprise and edge systems can use precision air cooling with containment and, where conditions permit, free cooling. Higher air-cooled densities may use active rear-door heat exchangers connected to a chilled-water loop. Rack-scale AI systems can require warm-water direct liquid cooling for the main IT load, while residual air cooling serves equipment that still rejects heat to the room.

Cooling selection requires answers to five connected questions:

• How much heat enters the liquid and air paths?
• Which temperatures, flow rates, pressure limits, and water conditions does the IT equipment require?
• What capacity remains available during maintenance or a component failure?
• How will the facility reject heat at the site design ambient?
• Which monitoring, leak detection, treatment, and controls are required?

How the ModulEdge product range maps to projects

ModulEdge offers factory-built modular data center platforms from 20 kW to 2.3+ MW per deployment unit, scalable to multi-megawatt capacity. Rack layout, IT load, redundancy, cooling, and external scope are configured for the selected hardware and site.

These are starting points, not automatic selections. For example, an 80 kW enterprise requirement may fall within the Standard Series, a 500 kW dense air-cooled GPU installation may align with MDC-500, and a GB300 infrastructure block may require the MDC-2000 architecture. Site power, hardware, density, resilience, cooling interfaces, and expansion requirements still govern the final configuration.

MDC-500 is a three-module operational system, not a single 40-foot container. MDC-2000 is a prefabricated modular building. For MDC-2000, upstream MV switchgear, transformers, and standby generators are included only when the project scope explicitly adds them.

What ModulEdge supplies—and what remains project-specific

ModulEdge develops repeatable modular data center platforms and configures them for the selected IT equipment, site, cooling method, availability objective, and contract boundary. Its role is broader than supplying an empty enclosure, but the exact responsibility must be stated in the proposal.

According to its current product documentation, ModulEdge manufactures switchboards and related electrical and control assemblies. Specialist OEMs manufacture equipment such as UPS systems, generators, and transformers; when those systems are included, ModulEdge selects, engineers, assembles, integrates, and tests them within the project power architecture. The proposal should identify the manufacturer and exact ModulEdge scope for every major item. Factory integration and FAT cover the agreed factory scope. Site connections, SAT, integrated testing, commissioning, and local approvals remain part of the project delivery plan.

Do not infer from a platform name that ModulEdge is automatically the civil contractor, local installer, permitting party, prime contractor, or operator. The proposal should identify the legal and technical responsibility for design, manufacture, logistics, site work, system integration, commissioning, warranty, spares, and local service. It should also state the manufacturing location and current production capacity applicable to that order.

Standards and certification: where to start

No single standard replaces the project requirements, local law, OEM instructions, or an owner-selected certification program. A first compliance matrix should distinguish the facility design basis from the approvals and awards pursued for a specific site.

Design intent and achieved certification are different claims. Uptime Institute distinguishes review of design documents from certification of the constructed facility, which includes on-site performance demonstrations. A supplier relationship, an engineer's qualification, a management-system certificate, and a certified facility are also different forms of evidence.

What a credible supplier proposal should contain

A useful proposal shows how the supplier will turn the input brief into a tested operating system. At minimum, request:

• A scope and interface matrix. It should identify what is supplied, excluded, installed, connected, and tested by each party.
• A rack and load schedule. It should state the equipment configuration, nominal and peak rack loads, and the capacity reserved for network and service equipment.
• The power architecture. It should show distribution paths, redundancy, autonomy assumptions, grounding, metering, and external electrical interfaces.
• The thermal basis of design. It should state air and liquid duties, temperatures, flow, pressure, ambient conditions, redundancy, and outdoor heat rejection.
• Layouts and service clearances. The proposal should account for equipment replacement, cable and pipe routes, doors, manifolds, and maintenance access.
• An expansion plan. It should distinguish repeatable modules from shared infrastructure and explain whether later phases require work on live systems.
• FAT, SAT, and integrated test plans. Each plan should identify loads, failure scenarios, controls sequences, witnesses, and acceptance records.
• A dependency-based schedule. Long-lead equipment, design approvals, site works, grid connection, transport, and commissioning should be visible.
• Controls and data interfaces. The proposal should name BMS, EPMS, and DCIM protocols; APIs; licensing; data ownership and export; cybersecurity boundaries; and the process for replacing a controller or OEM component.
• Evidence appropriate to the claim. Ask for the product specification, sample acceptance records, relevant reference designs, and comparable project evidence that the supplier is permitted to disclose.
• Assumptions, exclusions, warranty, and service terms. Remote monitoring, local response, spares, training, and responsibility after handover should be explicit.

Treat certification language with the same precision. A design may target a resilience objective or receive a design-stage assessment, while certification of a completed facility is a separate event. Ask what was assessed, by whom, at which stage, and for which entity and configuration.

Common modular data center mistakes

• Choosing the enclosure before defining the IT load. Rack, network, power, and cooling requirements should determine the form factor.
• Comparing prices with different boundaries. Normalize external plant, site work, commissioning, controls, and service before deciding.
• Using average density for every rack. Compute, network, storage, and service racks can have very different loads.
• Ignoring part-load operation. Cooling and electrical systems spend much of their life below design maximum and should be evaluated across the expected operating range.
• Stopping the cooling calculation at the rack. Pumps, water conditions, controls, residual air loads, and outdoor heat rejection remain part of the system.
• Assuming factory-built means permit-free. Local planning, fire, electrical, environmental, and utility requirements still apply.
• Leaving site interfaces until fabrication is complete. Foundation, lifting, drainage, cable entry, pipework, and commissioning boundaries need early agreement.
• Ignoring controls and replacement paths. Proprietary interfaces, inaccessible operating data, and a single-source spare strategy can make later expansion or component replacement unnecessarily difficult.
• Using a product name as the specification. Capacity, resilience, scope, and performance must refer to the actual configuration.

Is a modular data center right for your project?

Modular construction is a strong fit when a project needs repeatable engineering, parallel factory and site work, phased growth, a purpose-built high-density environment, or deployment at a constrained location. It is less compelling when the project is a one-off building with few repeatable systems, no schedule pressure, and design requirements that will continue changing after fabrication should have started.

Begin the decision with the buyer-input table above. Available power, IT load, rack schedule, cooling interface, site conditions, resilience objective, external scope, and required in-service date are enough to identify a plausible platform and expose the engineering questions that remain.

Modular data center FAQ

What should I send for an initial modular data center assessment?

Send the site location, available utility power, initial and ultimate IT load, rack and hardware schedule, rack-level peaks, cooling interfaces, availability objective, expected external scope, required in-service date, and known permitting constraints. A supplier can identify a starting platform from those inputs and list what remains to be engineered.

Does factory-built mean the complete project is turnkey?

No. Factory integration covers the scope defined in the contract. Foundations, utility connection, external electrical or cooling plant, transport, lifting, final connections, local installation, permitting, and commissioning may sit with the supplier, owner, EPC, or local contractors. The interface matrix should assign every responsibility.

Can a modular data center expand without interrupting live IT?

It can be designed for phased expansion, but interruption risk depends on what is repeated and what is shared. Utility feeds, switchgear, cooling headers, controls, network, and site access must support the expansion sequence. The proposal should identify every live-system intervention required for the next phase.

Does a modular data center still need permits and site commissioning?

Yes. Factory integration reduces on-site assembly and interface risk, but the project still requires applicable planning, fire, electrical, environmental, utility, and site-acceptance processes. FAT does not replace SAT or integrated testing of the completed installation.