vibe.d: an asynchronous web toolkit for the D language

What vibe.d actually gives a D project

vibe.d is written in D and is published on DUB as vibe-d. The README describes it as an asynchronous I/O, concurrency and web application toolkit, and the claim is easy to test against the package contents: the top level of the repository carries http/, web/, redis/, mongodb/, mail/, tls/, crypto/, inet/, stream/, source/, utils/ and textfilter/ directories. That is a full stack for a service, not a single component.

The centre of it is a fiber based event loop. The program structure in the README shows the model: a callback receives a request and a response object, writes to the response, and the framework schedules everything else around it. listenHTTP takes a bind address and a handler, and runApplication hands control to the event loop so the process stays alive. Nothing in the sample blocks a thread, which is the point of the design.

The intended user is a D developer who would otherwise assemble an HTTP server, a router, a Redis client and a set of serializers from separate packages. The README notes that database support is included as a supplemental feature, so the package aims to be a complete development environment rather than a library you extend.

The family of sibling repositories

vibe.d is not one repository. The README describes a project structure spread across many, and this matters when you decide what to depend on.

vibe-d is the high level web and REST framework with HTTP, SMTP, Redis and MongoDB functionality. vibe-http is the HTTP client and server implementation, including WebSockets, proxy and sessions. vibe-stream adds advanced stream types and TLS stream support. vibe-inet holds internet standard functionality such as URL handling, form encoding and HTML encoding. vibe-core is the fiber based I/O and concurrency implementation, eventcore is the low level abstraction over the operating system's asynchronous I/O facilities, and vibe-serialization covers serialization and structured data formats. The list continues with vibe-container, vibe-sdl for SDLang, and vibe-compat for legacy functionality.

Two entries are not part of the same family. observable implements observable, signal and slot, and reactive value patterns, and diet is a pug.js inspired compile time HTML template system with vibe.web integration, hosted in the rejectedsoftware organisation.

The practical effect is that the dependency you choose determines how much you inherit. Taking vibe-d pulls in the whole stack. Taking vibe-core plus vibe-http gives you the event loop and HTTP without the web layer, which is the route for a service that is not a website.

Creating and running a first project with DUB

The README recommends DUB over installing vibe.d directly, because DUB handles the dependency graph and the build. With DUB installed, a new project is three commands:

dub init <name> -t vibe.d
cd <name>
dub

The template flag copies a skeleton whose dub.sdl already declares the dependency, and the final dub command fetches and compiles. The same command runs any example, since the README notes that you can invoke dub from any of the example project directories.

The example directory is extensive and doubles as documentation. It includes app_skeleton, echoserver, http_server, http_static_server, https_server, https_server_sni, http_request, http_forward_proxy, http_reverse_proxy, http_info, auth_basic, auth_digest, json, diet, download, file_operations, message, mongodb, future, and a set of bench- projects including bench-http-server, bench-http-request, bench-urlrouter and bench-mongodb. Reverse proxy, digest authentication, SNI and WebSockets are the kind of feature that usually has to be researched before it is trusted, and here each has a runnable example.

The Hello Vibe.d server, line by line

The smallest complete program in the README carries its own dependency declaration inside a dub.sdl comment block, so it can be saved as a single file and run:

#!/usr/bin/env dub
/+ dub.sdl:
   name "hello_vibed"
   dependency "vibe-d" version="~>0.9.0"
+/
import vibe.vibe;

void main()
{
    listenHTTP("127.0.0.1:8080", (req, res) {
        res.writeBody("Hello Vibe.d: " ~ req.path);
    });

    runApplication();
}

The handler is a closure taking a request and a response. res.writeBody appends the body, and the concatenation operator in D is the tilde, so the response echoes the request path. runApplication at the end is the call that enters the event loop, which is why the program does not return from main.

Save it as hello.d and run it with DUB:

> dub hello.d

The script also carries a shebang, so on a system where it is marked executable, ./hello.d works directly. The README additionally points at run.dlang.io, where the same example can be run in a browser without a local D toolchain.

One detail to notice in that dependency line: the sample asks for version ~>0.9.0, while the tagged releases have reached 0.10.3. The bundled template and the sample therefore trail the current tags, which is a reminder to check the version constraint DUB writes into your dub.sdl before it reaches production.

Compiler support and the per-platform setup

The README states that vibe.d supports the 10 latest minor releases of DMD. The example given is that if the current version is v2.090.1, then v2.089.x down to v2.080.x are supported. Patch releases are described as desirable but not guaranteed, with only the last patch of a minor version guaranteed to work. LDC is supported as well, on the rule that an LDC release implementing a supported frontend version counts as supported.

For a generic Linux install, the requirements are DMD 2.088.1 or greater plus libssl:

sudo apt-get install libssl-dev

The Windows path asks for the DMD installer and the latest DUB release, and macOS can install DUB through brew:

brew install dub

The README warns against installing brew alongside macports, since the two conflict. OpenSSL is a native dependency on non-Windows systems, and each platform has a privilege lowering script, setup-linux.sh, setup-mac.sh and setup-freebsd.sh, which optionally create a user and group pair so the server can drop privileges after binding to a privileged port.

Release history and the pace of change

The project publishes tagged versions rather than GitHub releases, and the recent ones show where the effort went. v0.10.3, published on 2025-12-17, is titled for improved REST error handling and a better timeout on sendMail. v0.10.2, from 2025-03-11, introduced a safer Redis API and a REST @viaStatus feature, and v0.10.1 from the same day introduced WebRPC.

The last push to the repository was on 2026-07-04, and a CHANGELOG.md sits at the top level alongside the source, so the commit history and the changelog are the places to look before an upgrade. The current release cadence is slow in calendar terms, about nine months between the 0.10.2 and 0.10.3 tags, which tells you to budget for a framework that changes rarely and expects you to test against a specific version.

Licensing is MIT, with LICENSE.txt at the root and a German translation in LICENSE_DE.txt. The dual file is a translation rather than a second licence option, and a downstream project that redistributes vibe.d code should ship the MIT text as the LICENSE file requires.

Where vibe.d is the wrong choice

The first limitation is the language itself. If nobody on the team writes D, the toolkit cannot help, and the D compiler, DUB and the release model all have to be adopted before any of this matters. The README's own guidance about DUB, OpenSSL and per-platform privilege scripts describes a setup cost that a more common stack would not have.

The second limitation is the size of the surface. vibe.d bundles a web framework, a REST layer, SMTP, Redis, MongoDB, templating through diet, and serialization. If you need one HTTP client, taking the package means taking the stack, and the lower level repositories exist precisely so you can avoid that. The split is a strength for a careful dependency, and a liability for a quick prototype where the whole stack would be used anyway.

The third is documentation drift. The README points to vibed.org/docs and an API overview for the whole project, but the sample code in the README still pins dependency version ~>0.9.0 while the tags are at 0.10.3, and the DUB template is created with dub init -t vibe.d from a template that may lag the current release. For a framework you will depend on for years, that gap between the quickstart and the current tags is the thing to check before you commit, and the DUB package registry category library.vibed is where the compatible third party packages are listed for the specialised cases the high level package does not cover.

Editorial conclusion

vibe.d suits D developers who want a server, REST routing and database drivers in one dependency, and the repository's example directory covers the cases you would otherwise have to research yourself. It does not suit a team without a D toolchain, and its DUB template and dub.sdl still point at version 0.9.0 while the tags have reached 0.10.3. Check first that your DMD version falls inside the ten minor releases the README lists as supported.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vibe-d/vibe.d on GitHub