A whole machine with nothing else on it.
Quasar is dedicated bare metal managed by Carpathian and configured the same way a Spark instance is, with an optional GPU. It is not yet available to provision. This page exists so you can put your name against a specification and hear from us the day it ships.
Where this stands
The same answer you get on the pricing page, in the same words, so the two cannot drift apart while you are deciding.
Quasar appears on the pricing page with a rate and a note that it is not yet available to provision. That is still true, and nothing on this page changes it.
We would rather run a request queue and tell you where it stands than list Quasar as live and sort it out when you try to order one. When provisioning opens, the note comes off the pricing page and this page changes with it.
The account side of a dedicated server already exists in the dashboard. You can see the physical servers assigned to your organization, the packages attached to them, and the subscriptions that pay for them. You can request a server, upload files to it, subscribe to a package, and cancel a subscription.
What is missing is the path behind the request that turns it into a running machine. That is the part still being built, and it is the reason a request today is a request rather than an order. It reserves nothing, it costs nothing, and it tells us what to buy first.
What Quasar will be
Written in the future tense on purpose. None of this is orderable today, and the specification of the first hardware we buy is not settled.
Dedicated hardware
A Quasar instance would be a physical machine rather than a share of a compute node. No other tenant on the box, and no neighbour able to affect what your workload gets. If the reason you are reading this is that a shared node cannot tell you who else is on it, that is the question Quasar is meant to answer.
Managed by Carpathian
You would configure a Quasar instance in the builder the same way you configure a Spark instance, component by component, and the same team would operate it. The machine would live in one of our two facilities in Des Moines, Iowa, US Central 001 for production and US Central 002 for disaster recovery. Both sit in the same metro, so that pairing is site redundancy rather than geographic redundancy. Cloud and dedicated services carry a 99.5% uptime SLA.
An optional GPU
A GPU is an option on the product rather than a separate product, and it is not something you can order today. We are not going to name a model or a count before the first hardware is bought, because that would be a guess printed on a marketing page, and guesses printed on marketing pages have a way of turning into commitments. Tell us what the GPU is for and it goes into the sizing.
Packages and subscriptions
Requesting a server, subscribing to a package, and cancelling a subscription are modelled in the dashboard today, alongside the view of the physical servers assigned to your organization. The provisioning path behind those actions is what is still being built, which is why a request joins a queue rather than reaching a rack.
Why we are not taking orders yet
Dedicated hardware is expensive to overprovision. Every machine bought before anyone asks for it sits in a rack drawing power and losing value, and a wrong guess about the first batch is an expensive guess to unwind.
Building the queue before the fleet lets us size that first batch against demand that exists rather than demand we hoped for. If most of the requests want memory and no GPU, that is what goes in first. If they want a GPU, the order changes.
The second reason is blunter. Telling you Quasar is available today would win the click and lose the account at the first provisioning attempt, and you would find out at the worst possible moment, which is after you had planned around it.
What to do in the meantime
Colocation is live in both facilities. If you own the hardware, you rent space, power, and bandwidth from us and your machine goes in our rack, which gets you a box with nothing else on it now rather than when Quasar ships.
If the driver is predictable performance rather than physical isolation, a Spark instance sized with headroom may already be the answer. Spark instances run on compute nodes we own and keep well under capacity, so the contention people usually buy dedicated hardware to escape is a smaller problem here than the one they left.
- Colocation, if you own the hardware and want it in our racks
- A Spark instance with headroom, if the concern is contention rather than isolation
- A place in the Quasar queue, if the machine has to be ours
Questions about the Quasar queue
When will Quasar be available?
Does joining the queue cost anything or commit me to anything?
Does the queue reserve a machine for me?
What can I use instead right now?
Why publish a price for something I cannot buy?
Will Quasar have a GPU?
How is this different from colocation?
Where would a Quasar machine run?
What you can buy today
Cloud instances and colocation are both live, and the pricing page carries the catalog rates for each. Quasar sits on that page too, with the same note about provisioning you have read here.
Put your name against a specification.
Tell us the machine you would want and what it is for. That is what determines which hardware goes in first, and it is the difference between a first batch built for the queue and a first batch built on a guess. Nothing is charged and nothing is reserved.