Managed installation
Eleven phases. Twenty-seven steps. One order that works.
What makes a Bicrypto install hard is not any single command — it is that they only work in one sequence, and the failures are quiet. Node before the app. The database before the workers. The proxy before anything is reachable. Hand us the server and you get back the finished stack, licensed and running.
$75 flat · one-off · paid in crypto · covers every addon you own
11phases
ordered task templates, concatenated into one run
27shell steps
core install — 36 if you own the Ecosystem addon
1SSH session
the whole run executes over a single connection
$75flat
however many addons are on your account
A half-finished install is not a broken one
The reason people dread a failed install at step nineteen is that most scripts make you start again at step one.
Completed work is always a contiguous prefix
Every heavy step is wrapped in a guard that writes a marker file when it succeeds and exits immediately if that marker is already there. Because steps run in order and a run stops at the first failure, the markers can only ever be an unbroken run from the beginning — which is what makes resuming safe rather than a gamble about what state the box is in.
So a re-run walks straight through the finished prefix, costing seconds rather than repeating twenty minutes of package installation, and picks up at the step that actually failed.
Steps after a failure are written down as skipped, never left looking finished — because the worst version of this is a run that reports success and leaves you to discover which half of it happened.
Nothing is changed on your box before it is checked
The single most dangerous moment in this whole process is editing a web server config that is already serving something.
It asks Apache whether the edit is valid before it reloads anything
Every config file it is about to touch is copied to a timestamped backup first, and the pair is recorded in a change list. The proxy block is inserted only at the correct nesting depth, not wherever a pattern happens to match. Then Apache’s own configtest runs.
Pass, and the config is reloaded gracefully — no dropped connections — and the backups are removed. Fail, and it walks the change list backwards, restores every file, and stops. Your server is left exactly as it was, rather than half-edited by a script that pressed on hopefully.
The six modules the proxy needs are enabled first, and Apache is only restarted for that if enabling actually changed something. The websocket upgrade is routed deliberately: it is the part that, when missed, leaves a trading UI that loads and then never updates.
Your root password is never in a row we keep
You are handing a stranger SSH access to a machine that will hold other people’s money. Here is exactly where the secret goes.
The stored command holds a placeholder. Only the wire holds the value.
Install commands live in our database with placeholders in them — a fixed, allowlisted set of twelve. At run time the encrypted secrets are decrypted and substituted only into the string handed to the SSH channel. The step row we keep, and the log an operator reads, both still say {ROOT_PASS}.
Your credentials reach us through an encrypted form and are held as AES-256-GCM at rest. The same applies to the download URLs for your paid builds: they are separately signed, expire after thirty minutes, and are re-checked against your licences at the moment of download — so a URL that leaks is a URL that has already stopped working.
When we hand back, rotate the password. Nothing on our side needs it afterwards.
What actually lands on your server
Grouped by the phase that puts it there, because the grouping is the ordering and the ordering is the product.
The panel and the platform
Virtualmin over Ubuntu 24.04, the post-install wizard answered, and a virtual server created for your site — so ongoing management is a control panel you already know how to use rather than a machine only we understand.
The runtime, pinned
Node 26 installed system-wide with the distro's own nodejs and npm purged out of the way, and pnpm 9 pinned beside it. That pinning is not fussiness — installing the latest pnpm onto a mismatched Node is the exact crash this pipeline was rebuilt to stop hitting.
Data, cache and workers
MySQL and Redis configured, the background workers registered under PM2, and the process manager configured so a short crash loop cannot leave your site permanently down — PM2's stock restart limit would do exactly that.
Bicrypto core and every addon you own
The core, then a pass over every addon on your account — extensions, providers, blockchains, mobile. It reads your server's own database first to see what is already installed, so a re-run skips what is there rather than reinstalling it, and one unpublished build cannot abort the batch.
Reachability and SSL
Apache configured to proxy the front end and the API — websocket upgrades included, which is the part that silently breaks a trading UI when it is missed — plus a certificate. It starts self-signed and becomes a real one as soon as your DNS points at the box.
Licences activated, then a smoke test
Every licence activated against the server it now runs on, and the whole thing exercised before it is handed back. If something we installed does not come up cleanly, we fix it before you see it.
Own the Ecosystem addon? Four more phases, nine more steps, same price.
ScyllaDB installed and configured with its own keyspaces, its API port deliberately moved off 10000 so it cannot collide with the Virtualmin panel, and a readiness wait before anything is allowed to talk to it. Those phases are gated on you actually owning the addon — a customer who does not is never run through them, and the run is 27 steps instead of 36.
Own a core and two addons? The install is free.
Not a promotion with an end date — an entitlement computed from what is on your account, every time you look at it.
The shorter of the two stacks sets the number
You earn min(cores, floor(addons ÷ 2)) free installs, and what is left is that minus the ones already claimed. Two addons buy an entitlement; a third does nothing on its own; a fourth buys another — but only if you own a second core to use it on.
Addons means extensions, providers, blockchains and mobile apps. A licence whose support window has lapsed does not count toward it until you renew — the dated window wins over a lifetime flag, deliberately.
It is recomputed against your licences at the moment you claim — nothing to apply for.
Before you buy
What your server needs
The install runs on a Virtualmin panel over Ubuntu 24.04 LTS or newer — 24.04 is the minimum Bicrypto supports, and 22.04 genuinely cannot run it. Give us a server that meets these specs, or a blank one we can prepare, and we handle the rest.
Do not have one yet? Buy a server in crypto — it deploys itself, and it arrives meeting every line below.
Server requirements
Make sure your server meets these before we start — it saves a round-trip.
- Core only: 4 GB minimum
- Core + ecosystem/addons: 8 GB minimum
- At least 2 cores (more cores = better stability)
- Must support the SSE 4.2 and PCLMUL instruction sets
- Ubuntu 24.04 LTS or newer — 22.04 cannot run Bicrypto
- Virtualmin control panel; we install & configure it for you
Not running Virtualmin yet?
We install on a clean Virtualmin panel. If your server has any other panel (cPanel, Plesk, CyberPanel, aaPanel…) or an existing setup, please reinstall it to a fresh, empty Ubuntu 24.04 first — most hosting providers offer a one-click OS reinstall. We'll then set up Virtualmin and the full stack for you.
FAQ
The questions people ask before they pay
Hand us the server. Get back a running exchange.
You pass SSH access through an encrypted form after purchase. Credentials are encrypted at rest, kept out of every command log, used only for your install — and you can rotate your password the moment we are done.
Questions first? Talk to us
- Timed end to end at 11.9 and 17.3 minutes on real installs
- A failure resumes at the failed step, not from nothing
- Secrets encrypted at rest and absent from every log