A custom server power supply should be commissioned only when a mandatory server requirement cannot be met by a supported catalog module or complete power assembly. The phrase can mean either a PSU engineered for a specific server or a standard PSU intended for a custom-built server, so the first task is to remove that ambiguity. If customization is necessary, the request for quotation should define the supplied hardware, its interfaces, and its required behavior during startup, normal load, workload excursions, source or module loss, service, shutdown, and recovery. A wattage target and outline drawing are not enough to produce comparable proposals.
Quick answer: use an operating-state specification, not a custom-parts wish list
A host-supported catalog assembly is usually the lower-risk choice when it meets the server’s electrical, mechanical, cooling, management, and availability requirements. Pursue customization when a documented requirement remains unresolved, such as an unusual input source, constrained enclosure, nonstandard DC bus, specialized management behavior, or controlled lifecycle need. The RFQ must then identify whether the supplier owns only the converter module or also the cage, PDB, harnesses, firmware interface, and cooling assumptions. For every required operating state, define the conditions, expected response, evidence method, and party responsible for proving it.
The customization gate starts with one unmet requirement
“Custom” is not an engineering objective by itself. It is a response to a specific gap between the server architecture and available hardware. A project should name that gap before requesting development. Otherwise, bidders may interpret the request as anything from changing an output connector to designing a new converter topology.
| Implementation route | When it is appropriate | Evidence that may already exist | Primary program risk |
|---|---|---|---|
| Supported catalog module or assembly | The target server, PDB, input source, airflow, firmware, and required power state are covered by published platform support. | Host compatibility records, model-specific specifications, established service procedures, and existing spare identities may be available. | Assuming that a similar-looking or similarly rated part is supported without checking the exact platform. |
| Modification of an established platform | The underlying conversion behavior is suitable, but a controlled change is needed to packaging, connectors, signals, output configuration, or another defined interface. | Parts of the original design evidence may remain useful, but their applicability after modification must be stated. | A seemingly narrow change can affect cooling, EMC, safety spacing, sequencing, approvals, or manufacturing control. |
| New converter or power assembly | A mandatory input, output, dynamic, mechanical, environmental, or control requirement falls outside available platforms. | Evidence must be developed for the resulting design and its installed server configuration. | Higher development scope, more unresolved interfaces, and greater responsibility for production and lifecycle control. |
A useful gate question is: What requirement would remain unsatisfied if the best supported standard assembly were used? The answer should be measurable. “We need something unique” is not a requirement; “the approved module cannot operate from the defined site source” or “the available assembly conflicts with the chassis cooling path” identifies an engineering boundary.
The distinction between platform adaptation and ground-up conversion is explored further in Powernexu’s discussion of the custom power-supply design boundary. A first-party custom system builder from Acopian also illustrates the broader sourcing principle that custom power work begins with defined system requirements rather than an undifferentiated request for a special PSU.
The RFQ noun must identify the deliverable
A supplier cannot allocate cost, responsibility, or evidence correctly until the requested item has a physical boundary. “Two custom server PSUs” might describe two bare converter modules, a redundant pair with a mating cage, or a complete power subsystem containing distribution and host interconnects. Those are materially different deliverables.
| Assembly element | Question the RFQ must answer | Typical interface consequence |
|---|---|---|
| Converter module | Is the supplier responsible for a fixed PSU, removable module, or module compatible with a specified host ecosystem? | Defines the input, regulated output, standby functions, protection behavior, airflow needs, and control signals. |
| Cage, guides, and retention | Who supplies the bay, rails, latch features, insertion stop, and extraction hardware? | Determines alignment, connector engagement, service clearance, and whether removal is possible in the installed rack. |
| PDB, busbar, or combining board | Does the quoted scope include source combining, isolation, current sharing, branch protection, and distribution? | Determines how module output reaches CPUs, accelerators, storage, fans, and standby loads. |
| Harnesses and mating connectors | Are mating parts, cable assemblies, terminal hardware, and pin definitions included? | Controls polarity, contact loading, voltage drop, routing, keying, and field replaceability. |
| Management integration | Who defines enable logic, status, alerts, telemetry, addressing, and firmware interpretation? | Determines whether the BMC can recognize healthy, absent, failed, or degraded power states. |
| Host cooling | Does the PSU include its own fan, rely on chassis airflow, or require coordinated fan control? | Connects usable output and component temperature to inlet conditions, pressure, airflow direction, and adjacent obstructions. |
The boundary should be shown in a one-page architecture drawing and repeated in the commercial bill of material. Customer-furnished parts must be listed as explicitly as supplier-furnished parts. If the customer owns the PDB, for example, the supplier still needs the electrical and mechanical interface data required to develop the module. If the supplier owns the complete assembly, the quotation should identify every included module, board, cage, harness, and accessory.
Server packaging terms do not close these relationships by themselves. The server PSU form-factor ecosystem explains why the bay, blind-mate interface, airflow path, controls, and service model must be treated as one contract. Connector appearance or an inferred pinout should never be used to authorize a custom interface.
For each required state, record the initial condition, triggering event, required PSU and server response, permitted limits, test configuration, evidence method, and responsible party. Keep source voltage, inlet temperature, airflow, module population, firmware revision, server configuration, and load waveform in the same record whenever they can change the result.
| State | Requirement to define | Evidence |
|---|---|---|
| Input, standby, and startup | Define input application, standby functions, rail sequencing, rise behavior, power-good timing, and unintended-start restrictions. | Time-correlated input, output, standby, enable, and status records. |
| Normal load and workload excursion | State continuous and peak load envelopes, duration, repetition, measurement boundary, source condition, cooling condition, and acceptable voltage response. | Representative programmable-load and installed-server measurements. |
| Source or module loss | Name the permitted loss, surviving load, transfer behavior, and required server continuity. | Bus voltage, module current, status, thermal, and host-event records. |
| Removal and insertion | If live service is required, define isolation, connector sequencing, inrush, remaining-path limits, and recognition of restored operation. | Transition waveforms, event logs, and connector inspection. |
| Protection event | Define responses to overload, short circuit, overtemperature, input disturbance, or cooling failure, including the permitted recovery method. | Fault-specific response and recovery tests at the named boundary. |
| Shutdown and recovery | Define rail and signal order, stored-energy decay, restart conditions, and host behavior. | Shutdown timing, restart records, and management logs. |
Rated power is only one matrix input. Optional functions such as redundant operation, live service, PMBus communication, or multiple input types should appear only when the server requires them. If a load waveform or boundary is unknown, assign it as an unresolved system input rather than asking the supplier to infer it.
Every shared interface needs a named author, reviewer, and approval authority. Unresolved values should remain visible with an owner and due point rather than being converted into supplier assumptions.
- Input: Source type, range, disturbances, protection, grounding, connectors, and upstream ownership.
- Main DC: Voltage behavior, return and current paths, mating interface, distribution drop, and measurement point.
- Control: Required enable, status, fault, sharing, fan, address, and communication functions, including logic domains and timing.
- Mechanical: Shared datums, guides, seating plane, retention, ventilation keep-outs, and service envelope.
- Thermal: Inlet conditions, airflow direction, pressure or fan assumptions, neighboring heat sources, sensors, and degraded-state cooling.
- Compliance: Intended markets and the evidence assigned to the PSU, power assembly, and finished server.
Maintain these definitions in a revision-controlled interface document tied to the PSU, PDB, chassis, harness, and firmware identities used for verification.
Make the evidence plan follow the same operating states
The evidence request should mirror the requirements matrix instead of arriving as a generic instruction to “test the PSU.” For each requirement, state whether the evidence will come from analysis, a supplier bench test, a component document, an inspection, or an installed-server test. The method should also identify the configuration and measurement boundary.
Consider a workload-transient requirement. The PSU supplier can apply a programmable-load waveform and record output response at the module terminals. The server integrator may need a second test at the PDB and load branches because distribution impedance affects what the processors or accelerators see. The host team may also need to correlate BMC records with faster oscilloscope data. None of those results substitutes for the others; they answer questions at different boundaries.
A staged evidence plan can reduce rework without implying that early prototypes are production units:
- Proposal review: Reconcile the supplier’s scope, exceptions, assumptions, inherited design evidence, and unresolved interfaces against the RFQ.
- Prototype characterization: Examine electrical states, protection behavior, thermal performance, mechanics, and communications on the defined prototype revision.
- Server integration: Exercise the actual chassis, PDB, firmware, cooling controls, representative workloads, and required failure or service transitions.
- Production baseline: Identify the approved hardware and firmware revisions, manufacturing test coverage, controlled documents, and acceptance records associated with released units.
Any modification that can alter compliance, thermal behavior, timing, or electrical performance requires an explicit assessment of which earlier evidence remains applicable. The original platform’s documentation may be useful, but it should not be presented as automatic proof for a changed configuration.
A comparable RFQ consists of six controlled records
The RFQ package does not need to be unnecessarily large. It does need to separate system facts from assumptions and commercial scope. Six coordinated records are usually more useful than one long narrative specification:
- Architecture sheet: A one-line power path showing facility input, converter modules, combining or distribution hardware, major load zones, standby path, and the requested supply boundary.
- Scope and bill of material: A list of supplier-furnished, customer-furnished, optional, development-only, and production items.
- Operating-state matrix: The initial condition, event, expected response, permitted boundary, and evidence for every required state.
- Interface control document: Mechanical datums, mating definitions, electrical interfaces, control behavior, management expectations, thermal assumptions, and document owners.
- Evidence matrix: The method, responsible party, configuration, acceptance rule, and retained artifact for each requirement.
- Lifecycle plan: Revision control, approved substitutions, change notification expectations, production-test scope, traceability, spares, and end-of-life responsibilities.
Suppliers can then return exceptions against named requirements rather than hiding differences inside prose. Commercial proposals also become easier to compare because engineering services, tooling, prototypes, test fixtures, compliance work, production hardware, and optional assembly components can be separated without losing their connection to the same configuration.
Keep the qualified configuration attached to the service part
A custom design remains useful only while production units and field spares correspond to the server configuration that generated the evidence. The controlled identity should connect the PSU revision to its mating PDB or harness, chassis cooling arrangement, host firmware baseline, applicable test records, and permitted substitutions. A spare labeled only by output wattage cannot preserve that relationship.
Lifecycle terms should address how changes to semiconductors, magnetics, fans, connectors, firmware, protective settings, or manufacturing locations will be assessed and communicated. The appropriate response to a change can range from document review to repeated testing, depending on which operating states and interfaces may be affected. The RFQ should define the process rather than assume every change is harmless or demand complete retesting without technical cause.
The strongest custom server power supply program does not begin with a special enclosure or a larger power number. It begins with one unmet requirement, places that requirement inside the server’s real operating states, and assigns every shared boundary to an owner. That structure lets suppliers quote the same deliverable, lets prototype evidence answer specific questions, and lets production and service preserve the configuration that was actually approved. If a supported catalog assembly already closes those requirements, it remains the cleaner answer; if it does not, the state-based RFQ explains exactly what the custom program must accomplish.
