Development & CI/CD
A Standing Build Server for Code Your Team Trusts.
Hosted runners too slow, or too expensive at your build volume? A standing VPS runner works well, with one hard rule: it only ever executes code your team trusts.
Every build is code execution. This server holds your deploy keys and caches, so only code you would run on your laptop belongs on it.
The Trust Rule
First Decide Whose Code Gets to Run
A standing runner suits repositories your own team controls. If strangers can open pull requests that trigger builds, stop here; that code needs disposable isolation, not a warm server full of secrets.
Your Team's Code Only
Builds come from repositories and people you control, with a clear rule for what triggers a run.
Small, Rotating Secrets
Deploy keys and tokens carry the least permission that still works, and you know how to rotate each one.
Every Job Cleans Up
Workspaces expire, caches have a size cap, and abandoned previews get deleted rather than discovered.
Commit to Preview
Follow a Commit from Push to Preview
A pipeline turns repository contents into running processes on your server. It is worth being deliberate about the three points where that can go wrong.
- 01
What Starts a Build
A webhook arrives, gets validated, and a job starts. Each job should see only the credentials it needs and nothing beside them.
- 02
The Job Itself
Give every build a workspace, a timeout, and a resource cap. The VPS does not isolate jobs from each other; that part is your setup's work.
- 03
What a Build Leaves Behind
Caches and artifacts expire on a schedule you set. Preview environments keep their own credentials, well away from production's.
The Box Itself
You Bring the Toolchain, We Keep the Box On
There is no hosted CI product here and no control plane. You install the runner and everything around it. In exchange, the caches stay warm between builds and nobody meters your minutes.
- Recreate your team's toolchainFull root access
- The same compilers, containers, and caches your builds already use, installed once and kept warm between runs.
- Benchmark real builds against the limitsPremium, Ultra, Max plans with current vCPU, RAM, NVMe, and monthly transfer limits
- Time a cold build, a cached one, and two running at once. Those numbers, next to the plan table, pick your size.
- Test both directions of trafficTokyo or Singapore
- The runner pulls from registries and pushes artifacts; reviewers open previews. The two flows can prefer different locations.
Runner and Reviewers
The Runner and the Reviewers Pull in Different Directions
Runner location decides how fast checkouts and dependency pulls run. Preview location decides what reviewers feel. Measure both before assuming one city wins.
Current mainland-China paths: China Telecom: CTGNet (formerly China Telecom CN2 GIA, AS23764 / AS4809); China Unicom: CUP (China Unicom Premium, AS9929 / AS10099); China Mobile: CMIN2 (China Mobile International N2, AS58807).
- 01Time a checkout, a dependency install, and an artifact upload from each location with your actual providers.
- 02For previews, click through a real page or API flow from the networks your reviewers sit on.
- 03Watch monthly transfer if jobs re-download the same dependencies or container layers every run.
Looking Glass output is a snapshot of the path at the moment you ran the test; day-to-day latency and app performance can differ. Read the network and locations pages for route terminology and facility context.
Sizing Builds
Size for Your Worst Normal Build
An average build time hides the one job that eats all the memory. Find your largest routine build, then decide how many can overlap before the box matters.
The Biggest Routine Job
Peak memory and scratch space during your heaviest build set the floor, not the average. Measure that job, then add margin.
When Builds Overlap
Two pushes in the same minute double everything. Decide whether jobs queue or run side by side, and size for that answer.
Caches Never Shrink on Their Own
Container layers, artifacts, and stale previews accumulate until a cleanup rule says otherwise. Write the rule early.
Premium
- 2 vCPU (AMD Ryzen 9950X)
- 4 GB RAM
- 40 GB NVMe
- 1 TB/mo transfer
Ultra
- 2 vCPU (AMD Ryzen 9950X)
- 8 GB RAM
- 80 GB NVMe
- 2 TB/mo transfer
Max
- 4 vCPU (AMD Ryzen 9950X)
- 16 GB RAM
- 160 GB NVMe
- 4 TB/mo transfer
What Not to Run
Strangers' Pull Requests Do Not Belong Here
Public repositories that build on pull request are the classic mistake. Unknown code deserves disposable isolation, far from a server that holds credentials and runs your other services.
Riven Cloud supplies an unmanaged Linux KVM VPS with full root access. Everything inside it, from the firewall to the backups, is yours to operate.
- Rotate tokens, deploy keys, and webhook secrets whenever exposure is possible. Cached credentials count.
- Keep preview data and release paths separate from production; a staging bug should never be able to reach live customers.
Further reading
Harden the Box Before You Automate It
Questions
Development & CI/CD FAQ
Is Riven Cloud a hosted CI service?+
No. You get a KVM VPS and install the runner or CI controller yourself, along with every integration around it. Wiring it up is your project; keeping the box on is ours.
Should preview and production share one server?+
Not if a preview could touch production credentials, data, or capacity. Separate accounts, secrets, and databases are the minimum, and the VPS does not draw that line for you. When in doubt, use separate boxes.
Sure Only Trusted Code Will Run Here?
Then time a cold build, a cached build, and your worst overlap, and put those numbers against the current plans.