Most modern web software assumes you have a build pipeline. You clone a repository, install Composer packages, bundle assets with Node, then run everything through Docker. That’s fine when you control the environment. It’s a lot less fine when you just want a forum online this afternoon.

bulletinbored takes the opposite approach: upload the files and it runs.

What “zero dependencies” actually means

  • No Composer. The core is plain PHP 8 and uses PDO, which ships with PHP.
  • No Docker. It runs on any shared host with PHP and a writable directory.
  • No Node or build step. Assets are served as-is; there is nothing to compile.
  • No external services. The database can be SQLite — a single file.

The only hard requirements are PHP 8.x with PDO, and either SQLite or MySQL. If you can upload files to a server, you can run bulletinbored.

Fewer moving parts, fewer surprises

Every dependency is a future security patch, a version conflict and a support question. By keeping the stack to PHP and PDO:

  • Upgrades stay boring. There are no transitive dependencies to reconcile.
  • The attack surface is smaller. Less third-party code means less to audit.
  • Backups are simple. With SQLite, the database is one file you can copy.

Extensibility without a package manager

None of this means the software is closed. bulletinbored ships a plugin and theme system that works with plain PHP files and CSS:

// plugins/hello/plugin.php
function hello_post_render(string $html): string
{
    return $html . '<p>Hello from a plugin!</p>';
}

register_hook('post.render', 'hello_post_render');

Drop the folder in and it’s active. Remove the folder and it’s gone — no lockfile, no autoloader, no cache to clear.

The trade-off

Zero dependencies is a deliberate constraint, not a lack of ambition. We give up some convenience to gain something more valuable for self-hosted software: predictability. You always know exactly what runs on your server, and why.

Read more in the architecture documentation, or grab the code on GitHub.