VulCode

Open source: our code in Proxmox VE, ILSpy and 69 other projects

Fixes that maintainers of other people's projects reviewed and merged into their code, and the tools we build in-house. Every project has its own page describing what we changed, with a link to each change.

All contributions Write-ups of the changes
The largest projects with our changes71 projects, 147 merged changes

Contributions by technology

We fix libraries in the languages we write in ourselves. Each technology page shows our projects, a code excerpt from one of them and every contribution in that language.

All technologies

Write-ups in Tech news

For selected changes we write up what was broken, what we fixed and how we tested it, with the code and a link to the pull request.

Contribution · Concourse

Concourse: task file vars are interpolated before the file is parsed

A var in a non-string field such as memory: ((container_mem_limit)) failed validation, because the task file was parsed before its vars were resolved. The issue had been open since 2020.

Read the note
Contribution · Sonic

Sonic: TRIGGER backup works while a store is in use

Backups in the Sonic search backend failed right after data was written, because RocksDB will not open a database that is already open in the same process. The backup now uses the open store.

Read the note
Contribution · PHPMailer

PHPMailer: QUIT no longer ends up inside an interrupted message

When sending broke off in the middle of the DATA command, PHPMailer sent QUIT, the server took it as another line of the message and kept waiting. Now the connection is simply closed in that case.

Read the note
All write-ups

Why we fix bugs with the library's authors

A bug in a library can be dealt with in three ways, and each costs differently over time. We take the third: until a release with the fix is out the project runs on a pinned version with the patch, then it goes back to the official one.

  • A workaround in the project code

    At the start
    Works immediately: an extra check before the library is called.
    With every later version
    Code stays that exists only because the library has a bug. When the library fixes it, the workaround remains as dead code nobody dares to remove.

  • Your own copy of the library

    At the start
    The fix sits where it belongs: in your own copy of the library or in a patch applied to the installed package.
    With every later version
    Every update means reapplying and checking the patch, and a security fix arrives only once someone moves the changes across by hand.

  • A fix sent to the library's authors

    At the start
    The slowest: a test that reproduces the bug, code in the project's style and a review that can take days or weeks.
    With every later version
    The authors maintain the fix, it runs through their tests in every release and reaches every user, and the project goes back to the official version with no local changes.
The full post: why we fix other people's code

Our projects

We build Vulp, Gyred and Plazer from the ground up in-house. Each has a portfolio page with its screens and a description of how it works.

  • Vulp: the app's screen

    Vulp

    Every one of our repositories from a single terminal.

    Vulp is our in-house terminal tool: one screen shows the state of every repository, a batch sync pulls and pushes changes at once, and projects, todos, pull requests and statistics sit under keyboard shortcuts. Written in Rust so it stays instant.

    • The state of every repository on one screen
    • Batch sync across many repos at once
    • Projects, todos and pull requests at hand
    • Commit and activity statistics
  • Gyred: the app's screen

    Gyred

    A control plane for AI agents that work on their own.

    Gyred keeps a fleet of agents in line: workspaces separate projects, rules say what an agent may do, and loops carry a real stopping condition instead of spinning forever. Leases make sure two agents never grab the same task - one takes it, the rest wait.

    • Workspaces for separate projects
    • Rules that limit what an agent may do
    • Loops with a real stopping condition
    • Leases that stop duplicated tasks
  • Plazer: the app's screen

    Plazer

    A messenger that has no idea what you are talking about.

    Messages, servers with channels, voice calls and profiles in one lightweight app. Your device encrypts direct messages, groups and private channels, the code is open, and you can host the server for your community yourself.

    • Encryption on your device: direct messages, groups and private channels
    • Servers with channels, roles and voice calls
    • An account without an email or a phone number
    • A native app for desktop, phone and browser

How we add our brick to the wall

Our part in open code does not take one shape. We do it in four different ways - each one feeds the others.

Custom software services

We build software to order: websites, panels, stores and apps. The client owns the code and gets the full commit history, not a locked black box. Many of the patterns and tools we work out here later flow back into our open projects.

Running our own OSS projects

We maintain our own open projects - like vulp - with a real repo, releases and care for quality. These are not abandoned experiments: we watch the issues, write documentation and keep developing them because we use them daily ourselves. Anyone can step in, read the code and build on top of it.

Contributing to other code

When we find a bug or a missing feature in a library we use, we do not patch it quietly on our side - we send the fix upstream. We file issues, open pull requests and help keep alive the tools our own work stands on. It is plain fairness toward the ecosystem we rely on.

Ready-made SaaS platforms

Some of our projects grow into full SaaS platforms where someone can simply sign up and get to work. The core of these platforms often shares code with the open tools, so developing one drives the other. Instead of inventing everything from scratch on every job, we have proven foundations we built ourselves and understand end to end.

We do not stand still

We are not bragging about one good month. On the left, numbers from our whole history in open code; on the right, the activity graph from the last 90 days - dense and without long gaps, because open source is a daily habit for us.

25,000+
commits since 2020
6 M+
lines of code
630,000+
OSS stars
70+
OSS projects contributed to
198 M+
characters of code
Activity, last 90 days
Jul
Aug
Sep
Oct
45 active dayslessmore

What we build in the open

Open code is not one type of project for us. From terminal tools, through platforms and apps, to emulators and libraries.

01Developer tools

Terminal tools we run ourselves every day, the kind that save us hours of clicking. The flagship is vulp - from a single terminal window it manages many repositories at once, syncs them, opens pull requests and gathers statistics. On top of that it enforces guardrails so nothing lands in a bad state. We build them for ourselves first, so they have to be fast and dependable.

02Platforms and panels

Full control planes and platforms that pull many moving parts into one readable dashboard. One such project is Gyred - it runs a whole fleet of AI agents from a single place, shows their state and lets you steer them in real time. In the same spirit we build hosting and client panels where everything important is within reach. The point is that complex infrastructure can be grasped at a glance.

03Messengers and apps

Apps written from scratch, where a single codebase serves web, desktop and phone at once. The flagship is Plazer - a live-chat messenger with end-to-end encryption, so the content of messages stays between the people talking. Instead of snapping ready-made blocks together, we build these apps layer by layer and stay in control of every detail. That way they work equally well on every screen.

04Emulators and engines

We go down to the lowest layers, where every clock cycle counts. We write CPU emulators verified bit for bit - from CHIP-8 to the Game Boy - so they behave exactly like the original chip. On top of that come game engines and renderers built from the ground up, with no ready-made drawing libraries. It is the most demanding part of what we do, and the one we learn the most from.

05Libraries and microframeworks

Small, well-tested libraries and microframeworks that do one thing and do it properly. We build them only on the language standard library, with no heavy dependencies dragging half the internet along. That keeps them light, easy to drop into another project and predictable to maintain. We cover each one with tests before we call it done.

06Bots and automation

Discord bots, webhook proxies and ops scripts that take over the dull, repetitive work. They take load off the team and watch the infrastructure on their own, reacting before anyone even notices a problem. Instead of clicking through panels by hand, we describe once what should happen automatically and leave it to the machine. They give us more time for the things that cannot be automated.

Questions about open source

See how we write - in the open

All of our open source is public: repositories, commit history, releases. Take a look, read the code, clone it and build on top of it.

See the code on git.vulcode.com
vulp
vulp TUI