OpenVK: an open source CMS that imitates the old VKontakte

A fan project, and the project says so twice

OpenVK is described as an attempt to create a simple CMS that imitates old VKontakte, and the README is careful about two things: the relationship to VK, and the state of the code.

The warning block says OpenVK is a fan project, not affiliated in any way with VKontakte or its company VK LLC, and the same message is repeated in Russian. That is worth reading before you look at the feature set, because the resemblance is the point of the project and the trademark position is not.

On stability, the wording is unusually candid. Code provided here is not stable yet. And then, in the next paragraph: to be honest, we don't know whether if it even works. However, this version is maintained and we will be happy to accept your bug reports in the bug tracker, and you should also be able to submit them using the ticketing system, for which you will need an OpenVK account.

That is an interesting position for a project of this size, and it frames the rest of the documentation. Everything below it is written for someone who is going to run it and expect to fix things.

The primary language is PHP, the licence is LGPL-2.1, the default branch is master, the homepage is openvk.org, and the last push was on 2026-10-19. The release history is the outlier: public_preview_4 from 2022-06-26, public_preview_3 from 2022-02-02 and public_preview_2 from 2020-06-26. So the branch is active, but the last named release is a technical preview from 2022.

Getting a copy, and the two database requirement

The When's the release section answers the question directly. They will release OpenVK as soon as it is ready, and for now you can either git clone the master branch and use git pull to update, or grab a prebuilt distro from the GitHub artifacts, which is a nightly build archive.

The installation procedure is a numbered list, and the requirements come first. You install PHP 8.4 or later, a web server, Composer and NPM. Then a MySQL-compatible database, with MariaDB or Percona Server recommended, any MySQL-compatible server should work too, and a server compatible with at least MySQL 5.6 with 8.0 or later recommended. Support for MySQL 4.1 and up is work in progress, and in that case you replace the utf8mb4 and utf8mb4_unicode_520_ci references with utf8 and utf8_unicode_ci in the SQL.

Then the code goes in place:

git clone https://github.com/openvk/openvk /opt/openvk

and the dependencies are installed:

cd /opt/openvk && composer install
cd Web/static/js && npm install

Step five is the one that catches people out. You need 2 databases, one for the main data and another for events. That split is not a detail, because the events database is what the real-time notification system writes to, and the two are backed up and scaled on different schedules.

The remaining steps are a configuration copy from openvk-example.yml to openvk.yml, a migration run, and pointing the web server at the htdocs directory:

cd /opt/openvk && ./openvkctl upgrade

The nginx example configuration is linked from a separate Chandler repository, and you make sure the root is set to the htdocs directory.

The default administrator account is published in the README

Once you are done with the installation, you can log in to a default system administrator account on the site itself, with no registration required.

The login is `[email protected]` and the password is `admin`. The README then adds the note that it is recommended to change the password of the default account or disable it.

This is standard practice for a self-hosted CMS, since an installer cannot know what credentials you want, and the documentation is honest about the consequence. But it is worth being clear that the published default works on any instance that has not changed it, which means it is a first thing to check after deploying anything to a public address.

The alternative to this pattern, which the project does not describe, is to disable the account before the instance is reachable at all. That is a deployment ordering question rather than a code question, and it is the kind of thing that is easy to get wrong with a checklist of ten steps.

The same applies to the database credentials in your openvk.yml, and to the fact that the admin account exists at all in a fresh install.

The Chandler restructure changed the install procedure

There is a second warning block in the installation section, and it is the one that will bite you if you follow an older guide.

OpenVK installation procedure has been changed after code restructurisation. Now you don't need to install Chandler separately and install OpenVK as its extension.

If you are migrating from the old structure, you make a backup of your Chandler and OpenVK installation, do a git pull, and consult the migration script, which is `php bin/upgrade-structure.php --help`, and it is recommended to use the --extract flag to move the openvk directory out of Chandler's folder. After the migration, you change the webserver's DocumentRoot from Chandler's htdocs to OpenVK's htdocs.

So the architecture is a single application now, where it used to be a CMS framework with OpenVK as a plugin inside it. The repository layout reflects the current shape, with Web/ for the web interface, VKAPI/ and ServiceAPI/ for the two API layers, CLI/ and bin/ for the command line tools, and a Vagrantfile plus install/ for the deployment helpers.

The old Chandler dependency is also why an nginx example lives in the OpenVK/chandler repository rather than in this one, which is the sort of split that makes old guides break.

There is an auto-install script for FreeBSD 15 as well:

pkg install wget
wget https://github.com/OpenVK/openvk/raw/refs/heads/master/install/automated/freebsd-15/install
chmod +x install
./install

And for containers there are separate Docker and Kubernetes instructions under install/automated, referenced but not reproduced in the README.

Real-time notifications need Redis, and Kafka is gone

The real-time notifications section is short and it clarifies what the events database is for.

You can install Redis to take advantage of real-time notifications, if you enabled Event DB in the config. The steps are to install Redis from your OS package manager, and to set notificationsBroker under credentials to true. It should work out of the box, and if not you tweak the Redis and OpenVK config settings.

So the events database is the durable record and Redis is the transport for live updates. That is a sensible split for a social network, where a notification has to be replayed when someone comes back online but does not need to be stored twice.

The following warning is the useful part. Kafka in OpenVK was deprecated since a specific commit and is no longer used in the OpenVK codebase, and if you see any mention of Kafka in source code, config or documentation, you should know that this will not work at all.

That is a documentation debt warning, and it is worth taking seriously in a project this size with a configuration file. A config key for a broker that no longer exists will be silently ignored, and the symptom is notifications that never arrive, which is hard to trace back to a deprecated dependency.

The system requirements for the whole stack are modest: any dual-core 1GHz or better CPU, at least 2GB of RAM with a recommendation of 6GB or 8GB for OpenVK with Redis, and a minimum database space of 10GB.

Hosting your own instance, and the licensing question

A list of public instances lives in the project wiki, and you can create your own, which the README encourages.

The constraint it gives is about PHP extensions. OpenVK requires extensions that may not always be available on web hostings, namely sodium and yaml, and these extensions are available on most of ISPManager hostings. That is why it is recommended to host your instances on VPS or VDS or dedicated servers.

So shared hosting is out, not because of the requirements themselves but because the extension set is not reliably present. That is a realistic answer for a PHP application of this shape, and it also tells you what the install expects: two databases, a web server, a message broker for live updates, and a fair amount of disk.

The licensing question is answered with some care. If your website uses OpenVK, should you release its sources? It depends. You can keep the sources to yourself if you do not plan to distribute your website binaries. If your website software must be distributed, it can stay non-OSS provided the OpenVK is not used as a primary application and is not modified. If you modified OpenVK for your needs, or your work is based on it and you are planning to redistribute this, then you should license it under terms of any LGPL-compatible license, such as OSL, GPL or LGPL.

That is a plain statement of what LGPL-2.1 means in practice, and it is worth reading before you fork the thing.

Localization is handled through Weblate, or by pull request, with the language data kept in a separate locales repository and the list of languages maintained in a list.yml file, in iOS String format.

Editorial conclusion

Adopt OpenVK if you want to run a VKontakte-style community on your own infrastructure and you can host it on a VPS with PHP 8.4, a MySQL-compatible database and Composer. Do not adopt it expecting a production-ready product, because the README says the code is not stable yet and that the maintainers do not know whether it even works, and the last tagged release is a 2022 technical preview. Before you install, plan for two databases, one for main data and one for events, and note that the nginx and Docker or Kubernetes instructions live in separate directories, and that Kafka has been removed from the codebase so any mention of it is obsolete.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. OpenVK/openvk on GitHub
3. Project website
4. README
5. Releases