Sales-catalog locations
12 locations
Locations currently listed in the Prism Nodes sales catalog.
Prism Nodes transparency report
How we run Prism Nodes.
This report explains how Prism Nodes manages capacity, measures support, operates its public fleet, and protects customer data. It keeps published facts separate from measurements that are not yet available.
Scope
A concise operational record
The first cycle establishes definitions and source boundaries before utilization and support numbers are published.
Preface
A note from the operators
Why Prism exists, and what we learned before building it.
We started Prism after years as systems administrators and Minecraft developers for some of the game's largest server communities, including Hoplite, Bliss, and Strength. That work taught us to keep busy systems predictable, draw clear capacity boundaries, answer people directly, and prevent problems before they become drama.
Prism carries those lessons into hosting. We keep the stack understandable, choose hardware for the work it must do, and pass the resulting efficiency back through practical plans and fewer opaque markups. This report is where we explain those choices, admit what we have not measured yet, and make the service easier to trust without asking anyone to take our word for it.
Method
A measurable standard
A transparent report is useful only when its terms are clear and its limits are visible.
Product pages explain what Prism sells: server plans, hardware tiers, locations, and the tools available in the panel. This page explains what Prism measures about operating that service. It is intended for customers, prospective customers, and anyone who needs to understand the difference between a product statement and an operational result.
A missing measurement is labeled as missing rather than estimated. The dash in this report is not a zero, a target, or a forecast. It means that the underlying reporting window is pending. Publishing the definition and source now makes later values comparable without creating a number simply to fill a card.
Verified facts
At a glance
These are source-backed facts for the first public cycle. Definitions and source labels stay with each value.
Off-site backup capacity
18 maximum off-site backup slots
Maximum off-site backup slots exposed by the published plans.
Advertised uplink
Up to 25 Gbps
Advertised uplink capacity for the game hosting platform.
Support availability
24 / 7 human support
Advertised availability of human support.
Fleet utilization
Capacity without the guesswork
Capacity reporting starts with the hardware and allocation model customers can verify today.
The public Performance tier is built around AMD Ryzen 9 9950X processors, while the Basic tier uses Ryzen 9 7900. Both are described with DDR5 memory and Gen 4 NVMe storage. Prism presents these as dedicated-resource plans: the allocation is designed to keep a customer's resources stable rather than treating the host as an undifferentiated pool. Those product descriptions establish the equipment and the intended service model; they do not by themselves establish how much of the fleet is busy at a given moment.
The main site states that much of the fleet is specified and built in-house, including Performance-tier nodes in flagship locations. Where an in-house deployment is not practical, Prism uses selected infrastructure partners held to a similar hardware standard. This is a mix, not a claim that every rack or every location has the same ownership path. The location view below therefore describes sales availability rather than inferring a uniform physical topology.
Allocation philosophy
Dedicated is a boundary, not a benchmark.
A resource label is useful only when it names what is actually reserved. Performance still depends on the processor, the rest of the node, and how the scheduler behaves under load.
“Dedicated” is often used as shorthand for several different products. A dedicated machine gives one customer the whole host. Dedicated cores reserve specific execution resources. A dedicated allocation enforces a defined CPU or memory entitlement while the operating system schedules work across a shared machine. Those boundaries are not interchangeable, and none of them is a performance result by itself.
Pinning a process to particular threads can improve isolation and predictability, especially near saturation, but it also removes choices from the kernel scheduler. With a flexible CPU share, we can make a much larger set of logical threads available and let the kernel place runnable work wherever headroom exists. A server can therefore use more threads for bursty or parallel work than it could from a small pinned set, while its CPU-time entitlement still limits how much total compute it can consume. Access to more eligible threads is not a promise of more CPU. Even pinned workloads still share parts of the processor package, memory subsystem, storage path, cooling envelope, and boost budget, so load elsewhere on a node can still matter.
- Dedicated machine
- The customer controls the entire physical host.
- Dedicated cores
- Specific physical or logical execution resources are reserved.
- Dedicated allocation
- An enforceable entitlement is reserved on a host the scheduler can still balance.
Our view is that a plan should state the boundary, publish the machine beneath it, and show node pressure over time. The word “dedicated” should never have to carry all three claims.
External experiment
What Birdflop’s scheduler test adds
Birdflop compared a 400% CPU limit with four pinned logical threads while Chunky generated terrain on six otherwise identical Minecraft servers.
One active server
Flexible share led
The WIP writeup reports an 8.3% multithreaded improvement for the CPU limit over four pinned threads at low node load.
Two active · 33% node CPU
The result was mixed
Chunk generation was statistically indistinguishable at the stated confidence level, while 95th-percentile MSPT was lower with the flexible limit: 232 ms versus 266 ms.
Six active · 100% node CPU
Pinning led multithreaded work
The writeup’s conclusion favors pinning for multithreaded throughput at saturation. Full node saturation is a boundary condition, not the operating target we want customers to experience.
Moderate-load tail latency
95th-percentile MSPT at 33% node CPU
Lower is better. Values rounded from the Birdflop writeup.
| Allocation | 95th-percentile MSPT |
|---|---|
| 400% flexible CPU limit | 232 milliseconds |
| Four pinned logical threads | 266 milliseconds |
Source: Birdflop, “Pinning vs. Threads” (WIP) Published test setup
Why specifications matter
A customer should be able to evaluate the boundary.
A CPU model without an allocation policy hides contention. An allocation without the CPU model hides per-core capability. Both without node utilization hide whether the host leaves enough room for real workloads to burst. Useful disclosure puts those facts together.
- 01
Processor Exact model, generation, and relevant core topology.
- 02
Allocation Whether limits mean a whole host, pinned cores, or schedulable CPU time.
- 03
Node context Memory, storage, network, and the utilization window around the workload.
- 04
Evidence Definitions and historical measurements, not an isolated best-case benchmark.
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Future capacity reporting will show how the fleet behaves over time rather than freezing a single snapshot into a headline number.
Fleet utilization history
Host utilization over time
A historical series will be published after a completed reporting window.
Series
- Host CPU Not yet reported
- Host RAM Not yet reported
Not yet reported
| Reporting month | Host CPU | Host RAM |
|---|---|---|
| Aug 2025 | Not yet reported | Not yet reported |
| Sep 2025 | Not yet reported | Not yet reported |
| Oct 2025 | Not yet reported | Not yet reported |
| Nov 2025 | Not yet reported | Not yet reported |
| Dec 2025 | Not yet reported | Not yet reported |
| Jan 2026 | Not yet reported | Not yet reported |
| Feb 2026 | Not yet reported | Not yet reported |
| Mar 2026 | Not yet reported | Not yet reported |
| Apr 2026 | Not yet reported | Not yet reported |
| May 2026 | Not yet reported | Not yet reported |
| Jun 2026 | Not yet reported | Not yet reported |
| Jul 2026 | Not yet reported | Not yet reported |
- Source
- Fleet utilization telemetry
- Window
- Reporting window pending
Future CPU utilization will be the time-weighted host CPU percentage. Future RAM utilization will be time-weighted used physical memory divided by physical memory. Both definitions exclude customer container limits, so a plan's configured ceiling is not mistaken for host pressure. The reporting window is still pending; no reporting date is promised here.
Customer operations
Support, measured by outcomes
Availability is a service commitment; response and resolution measurements require a defined record set.
Prism advertises 24 / 7 human support. This report does not turn that availability statement, a testimonial, or the contact page's within-24-hours email language into a measured result. Instead, the support series will describe outcomes from one consistent source: billing-portal tickets. That boundary keeps community conversations and general correspondence from being mixed into a support statistic they were never designed to represent.
The cards below are deliberately empty for the first cycle. They identify the exact population and calculations that will make future reports useful. A reader should be able to challenge a result, reproduce its inclusion rules, and understand why a ticket was or was not part of the calculation rather than relying on an attractive but ambiguous average.
Median first response
—
Not yet reported
Billing portal tickets only; excludes Discord, direct email, automation (notifications and acknowledgements), spam or abuse, and merged duplicate records. First response is elapsed wall-clock time from ticket creation to the first human staff reply. Median (p50) uses all qualifying human first replies sent within the reporting window.
90th-percentile first response
—
Not yet reported
Billing portal tickets only; excludes Discord, direct email, automation (notifications and acknowledgements), spam or abuse, and merged duplicate records. First response is elapsed wall-clock time from ticket creation to the first human staff reply. The 90th percentile (p90) uses all qualifying human first replies sent within the reporting window.
Tickets resolved
—
Not yet reported
Billing portal tickets only; excludes Discord, direct email, automation (notifications and acknowledgements), spam or abuse, and merged duplicate records. Resolved means the count of unique qualifying tickets moved to final Closed status within the reporting window; a ticket reopened before report cutoff is not counted.
Included records
Support reporting includes billing-portal tickets only. It excludes Discord, direct email, automated notifications and acknowledgements, spam or abuse, and merged duplicate records. The source label for every support card is Billing support ticket export.
Response and resolution
First response is elapsed wall-clock time from ticket creation to the first human staff reply. Median and 90th-percentile first response use all qualifying human first replies sent within the reporting window. Tickets resolved is the count of unique qualifying tickets moved to final Closed status within that window; a ticket reopened before report cutoff is not counted.
The support series will track the same ticket population used in the cards, so response trends and resolution counts stay tied to one auditable source.
Support history
Response outcomes over time
A historical series will be published after a completed reporting window.
Series
- Median first response Not yet reported
- 90th-percentile first response Not yet reported
Not yet reported
| Reporting month | Median first response | 90th-percentile first response |
|---|---|---|
| Aug 2025 | Not yet reported | Not yet reported |
| Sep 2025 | Not yet reported | Not yet reported |
| Oct 2025 | Not yet reported | Not yet reported |
| Nov 2025 | Not yet reported | Not yet reported |
| Dec 2025 | Not yet reported | Not yet reported |
| Jan 2026 | Not yet reported | Not yet reported |
| Feb 2026 | Not yet reported | Not yet reported |
| Mar 2026 | Not yet reported | Not yet reported |
| Apr 2026 | Not yet reported | Not yet reported |
| May 2026 | Not yet reported | Not yet reported |
| Jun 2026 | Not yet reported | Not yet reported |
| Jul 2026 | Not yet reported | Not yet reported |
- Source
- Billing support ticket export
- Window
- Reporting window pending
System view
How the platform is put together
Four layers describe the public service without implying a topology that has not been published.
Compute
Dedicated-resource hosts
Performance uses Ryzen 9 9950X and Basic uses Ryzen 9 7900, with DDR5 and dedicated resource allocation described for the plans. Hardware is specified and built in-house for much of the fleet, with selected partners used elsewhere when deployment conditions require it.
Storage
Fast local media, separate archives
Gen 4 NVMe is the published serving-storage foundation. Customer backup archives are stored off the serving node on separate hardware, keeping the archive location distinct from the machine that serves a customer's running workload.
Network and protection
Multiple public protection names
The service advertises up to 25 Gbps uplinks and a public protection mix that names GlobalSecureLayer, OVH VAC, CosmicGuard, Path.net, and other providers. The list does not claim that every provider protects every location.
Control plane
Pterodactyl management
Pterodactyl is the published control-plane foundation for console, files, backups, plugins, and server operations. This report describes the interface customers use; it does not infer private service boundaries or internal deployment details.
Sales catalog
A location-by-location view
The twelve sales-catalog locations are grouped by region, with tier availability carried directly from the source rows.
Americas
Americas
Ashburn
Tier availability
- Premium
- Basic
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Americas
New York
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Americas
Dallas
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Americas
Los Angeles
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Americas
Miami
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Americas
Montreal
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Europe
Europe
Frankfurt
Tier availability
- Premium
- Basic
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Europe
London
Tier availability
- Premium
- Basic
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Europe
Paris
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Europe
Roubaix
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Asia-Pacific
Asia-Pacific
Singapore
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
Asia-Pacific
Sydney
Tier availability
- Premium
Average host CPU utilization
—
Not yet reported
Time-weighted host CPU percentage; customer container limits are excluded.
Average host RAM utilization
—
Not yet reported
Time-weighted used physical memory divided by physical memory total; customer container limits are excluded.
The sales catalog lists twelve locations. Prism Status monitors a different public component set that includes Amsterdam and does not list Paris or Roubaix. Availability follows the order page; active incidents follow Prism Status.
Operational history
A public record of operational events
This rolling view uses the incident and maintenance records Prism Status publishes publicly. It reports declared durations only; it does not infer availability, utilization, or impact beyond those records.
Loading public incident history. View Prism Status
Incidents
—
Awaiting feed
Aggregate declared incident minutes
—
Awaiting feed
Scheduled maintenance
—
Awaiting feed
Rolling 30-day view
Incidents by published day
Each bar represents incident records published on that UTC day.
Recent events
The latest public records
Incident and maintenance entries, newest first.
-
Recent events will appear when the Prism Status feed is available.
No event values are estimated while the public feed is loading.
Publication record
Transparency report archive
Each reporting cycle remains listed so later measurements keep their original context.
- Current report
First public reporting cycle
Established definitions, source boundaries, and the initial source-backed facts. Utilization and support reporting windows remain pending.
Resilience and communication
Data integrity is a system, not a checkbox
Protection is a set of separations and signals, not a promise that skips the underlying boundaries.
Customer backup archives are kept off the serving node on separate hardware. The published plans expose up to 18 off-site backup slots, giving customers a visible archive capacity rather than leaving the location of a backup implicit. That separation is the fact this report can establish; it is not evidence of a particular restore schedule or a guarantee about a specific recovery outcome.
Prism Status separately monitors Backup Infrastructure and Database Nodes. Those component names make integrity work observable as part of operations rather than reducing it to a badge on a sales page. Critical platform data also has off-site replicas, as supplied for this report. No replica count, region, schedule, encryption scheme, checksumming process, recovery objective, or restore-test cadence is inferred here.
Operational context
When something goes wrong
This page is a reporting record, not an incident channel.
A transparency report explains definitions and establishes a baseline; it should not be treated as a real-time statement about an outage, maintenance event, or account-specific problem. For current service state and notices, use Prism Status. For a question about an account, billing, or a server that requires customer-specific context, open a ticket through the billing support portal. Keeping those channels separate helps an operational notice reach the people who need it without rewriting this report after every event.
Definitions and sources
This cycle favors traceability over completeness. Hardware, network, plan, backup, and support-availability statements come from the public Prism Nodes product material; the location rows come from the sales catalog. The latency reference is the public ping test, while current component state belongs to Prism Status. Utilization and support cards remain explicitly unreported until their stated windows and qualifying records exist. The same rule will apply to every future metric: publish the definition and source with the value, and keep an unavailable result visibly unavailable.