DEV Community: Tiger

Stop the "It Works on My Machine" Madness: A Visual Comparison of Debugging Workflows

Tiger — Fri, 20 Feb 2026 01:45:29 +0000

Hey everyone,

I wanted to share this interesting comparison between a Traditional debugging workflow and a more modern Velovol Mode. We've all been there – a critical bug is found, but reproducing the exact environment for the developer is a massive pain.

This image perfectly illustrates the bottleneck:

Traditional Mode (Left): A planner finds a bug, but the programmer is busy on a different branch. Setting up the live environment to reproduce the issue is time-consuming and inefficient.
Velovol Mode (Right): The planner finds a bug and immediately creates a snapshot of the environment. They then quickly clone a "CLONE DISK" from the "BASE DISK" and share it with the programmer. The programmer receives the exact environment and can start investigating immediately, with no setup time required.

The Key Takeaway:
Using cloud-based snapshots and cloning can dramatically speed up the debugging process. It eliminates the "it works on my machine" problem by providing an exact replica of the buggy environment.

What are your thoughts on this approach? How does your team handle environment reproduction for critical bugs?

How to Set Up a Self‑Hosted Development Environment on Your Own Infrastructure (Step‑by‑Step Guide)

Tiger — Fri, 13 Feb 2026 01:38:08 +0000

This guide walks you through setting up a self‑hosted development environment platform on your own Linux infrastructure using ZFS for storage and Velovol to manage, snapshot, and clone developer environments. If you want to learn more about the product or follow along with screenshots, you can visit the official site at
https://www.velovol.com.

Prerequisites

Before you start, make sure you have:

One Linux server (physical or virtual) with sudo/root access.
A ZFS pool available on that server for storing development disks and snapshots.
Network access from your developers to this server (or to a reverse proxy in front of it).

Step 1 – Prepare a Linux Host with ZFS

Start with a clean Linux machine that will act as your dev environment host. Choose a modern distribution such as Ubuntu, Debian, or CentOS, and ensure it has enough CPU, RAM, and disk space to run multiple development environments at the same time.

Install ZFS if it is not already present, and create a ZFS pool dedicated to your development workloads. For example, you might attach one or more disks and create a pool like tank, then add a dataset such as tank/velovol that will store all base disks, snapshots, and clones. ZFS gives you copy‑on‑write snapshots and efficient cloning, which is exactly what we need for quickly spinning up reproducible dev environments.

Step 2 – Download and Start velovol-adm

Next, install the Velovol admin service, velovol-adm, on your Linux host. This component is responsible for managing projects, users, base disks, snapshots, and clones.

Download the binary or package from the official distribution source and place it in a suitable location on your server. Then start the service, either by running it directly from the command line or by configuring it as a systemd service so it starts automatically on boot. Once the service is running, verify it by checking the logs and, if a web UI is provided, by opening the admin interface in your browser.

Step 3 – Configure Portals

A “portal” is the entry point through which developers access their environments. Depending on your setup, this might be a web dashboard, an SSH endpoint, or integration with tools like VS Code Remote.

In the Velovol admin interface, configure one or more portals that match how your team prefers to work. For example, you can set a primary HTTPS URL such as https://dev.yourcompany.com and connect it to velovol-adm through a reverse proxy like Nginx or Caddy. Make sure DNS is set up correctly and that TLS certificates are configured so developers can securely reach the portal from their own machines.

Step 4 – Connect Velovol to ZFS Storage

With the admin service and portals in place, the next step is to register your ZFS storage in Velovol. This tells the system where to create and store base disks, snapshots, and cloned disks.

In the storage configuration section, point Velovol to your ZFS pool or dataset, for example /tank/velovol. Specify any quotas or limits you want to enforce per project or per user, and optionally tune ZFS options such as compression or record size based on your workload. Once configured, Velovol will use this ZFS backend to create efficient copy‑on‑write volumes for each development environment.

Step 5 – Create a Project

Projects are logical containers that group related environments, users, and resources. It is a good practice to create one project per product line, codebase, or team.

Open the Velovol admin interface and create a new project with a clear, descriptive name (for example, “Payments Service” or “Monorepo‑Platform”). Optionally add a description that explains what this project is for, what tech stack it uses, and which team owns it. This makes it easier to scale later when you have multiple projects and many users.

Step 6 – Create Users and Assign Roles

Now that you have a project, you can add users and define who is allowed to do what. Typically, you will have at least two types of users: administrators, who can manage base disks and settings, and developers, who consume the environments.

Within the project, create user accounts for each developer who needs access. Assign roles based on responsibilities: for example, platform engineers or team leads may have admin rights to create and update base disks, while regular developers only need permission to use existing snapshots and clones. This role‑based model helps you keep your environments consistent and secure as the team grows.

Step 7 – Create a Base Disk (Golden Environment)

The base disk is your “golden image” for development. It contains the operating system, language runtimes, tools, dependencies, and initial code checkout that every developer should start from.

Create a fresh environment that will become this base disk. Inside that environment, install your standard toolchain: compilers, package managers, build tools, database clients, and anything else your developers use daily. Clone the main repository or repositories, set up configuration files, and run any initial setup scripts so the environment can build and run the application. Once everything is configured to your satisfaction, save this environment as a base disk in Velovol so it can be reused as a template.

Step 8 – Mount the Base Disk and Start Developing

With the base disk defined, developers can now mount it and begin working. Mounting the base disk creates a writable working environment for an individual user, while still leveraging the underlying shared data to save space.

From the portal or admin interface, a developer selects the project and chooses the base disk as the starting point for a new environment. Velovol mounts this disk (or a writable layer on top of it) and exposes it through the configured access method, such as SSH or VS Code Remote. The developer can then open their IDE, connect to the environment, and start editing code, running tests, and installing additional tools as needed.

Step 9 – Unmount and Create a Snapshot

After configuring the environment to a desired state—for example, after adding specific dependencies or customizing the project setup—you can capture that state with a snapshot. Snapshots are point‑in‑time, read‑only copies of the disk that ZFS can create quickly and efficiently.

First, ensure that all important data is written to disk and that no critical processes are running. Then unmount the environment or stop any running sessions from the Velovol interface. From there, create a snapshot of the disk. This snapshot becomes a stable reference that you can always roll back to or use as the source for new cloned environments, without duplicating all the underlying data.

Step 10 – Clone the Snapshot for Other Users

The real power of this setup comes when you clone snapshots for other developers. Instead of each person manually setting up their own environment, you create one snapshot and then clone it as many times as you need.

In the admin interface, select the snapshot you created and use the cloning feature to create a new disk for another user. Assign this cloned disk to that user and allow them to mount it as their development environment. Because ZFS uses copy‑on‑write semantics, these clones are space‑efficient: they share the same data until changes are made, while still appearing as independent environments to each developer. This makes it easy to onboard new team members in minutes instead of days, and ensures everyone is working on an environment that is consistent, reproducible, and closely matches production.

Next Steps and Best Practices

Once you have this basic setup running, you can refine it further:

Establish a regular process for updating the base disk when dependencies or tooling change, and create a new versioned snapshot each time.
Use separate projects or datasets for different teams or services to keep resource usage under control.
Integrate this environment flow with your CI/CD and access management tools so that developers can move from code to production with minimal friction.

To explore more features, pricing, and additional guides, you can always refer back to the official Velovol website:
https://www.velovol.com.

Why we moved off AWS FSx: A technical comparison for Game Devs

Tiger — Tue, 03 Feb 2026 05:44:06 +0000

Optimizing storage is the "final boss" of game development infrastructure. Today, we’re comparing the industry-standard cloud solution (AWS FSx) against a self-hosted alternative (Velovol) across three critical use cases: Build Pipelines, Perforce Performance, and VDI.

The Challenge: "The Morning Sync"

If you work in Game Dev, you know the pain. "Hydrating" a build agent or a new developer's workstation with a 200GB+ project repo can take 30-60 minutes.

The industry standard solution, championed by NetApp and AWS, is to move everything to the cloud using Instant Thin Clones. But is that the only way?

Let's dive into the architecture.

Case Study 1: Accelerating Build Pipelines

☁️ The AWS + NetApp Approach

Mechanism: Instant Thin Clones.
The system creates writable, space-efficient clones of the golden master volume instantly in the cloud. Build agents mount these clones.

Pros: Excellent within AWS; saves storage via deduplication.
Cons: Performance is bound by cloud IOPS limits and network latency. You pay for every GB that moves.

🏠 The Velovol Approach (Self-Hosted)

Mechanism: Instant Virtual Mounting.
Velovol mounts the repository snapshot directly to the build agent's file system as a read-only or Copy-on-Write layer over your local LAN.

Pros: Works on ANY hardware (even that dusty server in the closet). No "cloning" delay—data is streamed on demand. Zero egress fees.
Cons: Requires the client on the build agent.

Winner: Tie. (AWS for pure cloud teams; Velovol for hybrid/on-prem performance).

Case Study 2: Perforce (P4) Performance

☁️ The AWS Approach

Leverages iSCSI Block Storage to provide high-throughput disk access for the Perforce server hosted in AWS. It outperforms standard NFS.

🏠 The Velovol Approach

Acts as a Distributed Edge Cache.
Instead of just speeding up the central server, Velovol eliminates the need for developers to talk to the central server for large assets. p4 sync becomes instantaneous because the heavy binary assets are virtually "already there" via the mount.

Winner: Velovol (for Developer Experience).

The Cost Reality Check

Running high-performance GPU instances in the cloud 24/7 for VDI is expensive.

Dimension	AWS FSx + NetApp	Velovol
Egress Fees	💸 Pay per GB	Zero (Local LAN)
Data Sovereignty	Shared Cloud Infra	100% Air-Gapped
Performance	Internet Latency	10GbE LAN Speed

Conclusion

If your studio is "all-in" on AWS and fully remote VDI, Amazon FSx is a formidable solution.

However, if your goal is to reclaim control over your data, eliminate the "cloud tax" on egress, and leverage the raw power of local RTX 4090 workstations without the wait times, you might want to look at self-hosted distribution.

Read the full technical breakdown on our engineering blog: Velovol Technical Deep Dive

How we reduced new engineer onboarding time from 2 days to 10 minutes

Tiger — Sat, 31 Jan 2026 03:48:57 +0000

1. The Problem

Start with a relatable story:

"It works on my machine." We've all heard it.
You hire a brilliant new engineer. They spend their first 3 days just wrestling with npm install errors, missing environment variables, and version mismatches.

We looked at cloud solutions like GitHub Codespaces or Gitpod. They are great, BUT:

Cost: They get expensive quickly for large teams.
Privacy: For some of us (especially in fintech/healthcare), sending our entire codebase and data to a third-party cloud is a non-starter.
Latency: Typing over a network connection never feels quite right.

2. The Quest for a Solution

Briefly mention what you tried (and why it failed):

We tried writing massive README.md files. (Nobody reads them).
We tried Docker Compose. (Better, but syncing huge data volumes was still a pain).
We tried extensive shell scripts. (Maintenance nightmare).

3. Introducing Velovol

So, we built Velovol.

Think of it as a "Self-Hosted Codespaces" that runs on your own infrastructure.

It solves the three biggest headaches:

Speed: It packages the entire environment state (not just code).
Security: Data never leaves your premise. It syncs from your internal storage directly to the developer's machine.
Versioning: Broke the environment? Rollback to the previous snapshot in seconds.

4. How it works (Under the Hood)

Velovol uses a client-server architecture.

Server: Manages environment snapshots and access control (Role-Based).
Storage: Connects to your existing internal storage (ZFS).
Client: Pulls the environment state and mounts it locally, so you get native performance.

5. Demo

Seeing is believing. Here is how fast you can spin up a fresh environment:

https://youtu.be/5vW6iN-7m6M?si=bGLZAg5iFF66cOf6

6. Try it out

We are currently in public beta/launch. If you are a team lead tired of onboarding hell, or a DevOps engineer who needs data sovereignty:

👉 Check out Velovol: https://www.velovol.com/

I'd love to hear your feedback in the comments below! What's your current onboarding struggle?