Alovoa: a dating platform where the business model is the feature

The differentiator is a list of refusals

Alovoa aims to be the first widespread free and open-source dating web platform, and the README answers the question of what makes it different from other platforms with a list of things it does not do.

No ads. No selling of your data. No paid features, and the parenthetical is specific: no pay super-likes, no pay to swipe, no pay to view profile, no pay to start a chat. No unsecure servers. No closed-source libraries. No seeing people you don't want to see with advanced filters. And your most private data is securely encrypted.

That list is the product in this case, and it is worth reading it as a set of design constraints rather than a marketing page. The last two entries are the load-bearing ones, and they are the ones that have a cost.

The no-seeing-people-you-do-not-want filter is a product feature that is unusual for a dating platform to commit to, because it removes a discovery mechanism. The encryption commitment is an architectural one, and the repository shows it, since the build instructions ask you to enter credentials for the database server, the email server and encryption keys in application.properties, and there is an alovoa.p12 file at the root of the repository.

The result is a platform where the reasons a commercial dating app has to be commercial, advertising, subscriptions and data sales, are all ruled out by policy, and the operator has to find some other way to pay for it. The donation links in the README make that explicit, with a list of platforms including Liberapay, Open Collective, a Ko-fi account, a Buy Me a Coffee page and a Bitcoin address, plus a dedicated donation list page on the site.

So the model is a non-profit or enthusiast project rather than a startup, and the audience for the code is operators and contributors rather than product teams.

The mobile app, the mirrors, and the translation workflow

Alovoa is also available as a mobile app, with the source code in a separate repository, alovoa-expo, which suggests the app is a separate native client rather than a wrapper around the site. The app is on F-Droid and on Google Play, and the F-Droid listing matters more than it might seem, because F-Droid is where you find software that has not been through a commercial app store's review process.

The project also maintains a Codeberg mirror, which is a common pattern for projects that want an independent copy of their source. The badge points at codeberg.org/Nonononoki/alovoa, so the mirror lives under an individual account rather than the organisation, which is a slightly less institutional arrangement than the GitHub original it mirrors.

The community infrastructure is broad for a project of this size. There is a Matrix chat room, a Mastodon account, a Twitter account, a subreddit and a testing website at beta.alovoa.com alongside the main one. Several of these are federated or decentralised platforms, which is consistent with the privacy position in the feature list rather than incidental.

The contribution path is spelled out in three items. Tell your friends about it and share on social media, described as the best way to make it grow. Improve the project by posting in Issues and making a pull request after issue discussion, which is a deliberate two-step process that keeps pull requests tied to an agreed plan rather than arriving cold. And translate the project into your preferred language on Weblate, with a translation status widget linked in the README.

That third item is the one that shapes the codebase, because Weblate manages the translation files in the repository rather than keeping them in a separate localisation system. A large web platform in many languages is a lot of string extraction work, and putting the strings under Weblate's management is what makes a large translation list achievable for a volunteer project.

Building from source, and the four things you have to supply

The build instructions are short, and the dependencies they list are the real specification of what this application needs.

Install OpenJDK 17. Install Maven. Set up a database, with MariaDB officially supported. Set up an email server or use an existing one, and any provider with IMAP support should work. Enter credentials for the database server, the email server and the encryption keys in application.properties. Then execute mvn install in the root folder.

Three of those four are services rather than libraries, and the email one is the easiest to underestimate. A dating platform has to send verification mail, and it has to read mail back, and the IMAP requirement means the deployment needs a working incoming mailbox, not just an outbound provider. That is a piece of infrastructure that a hobby operator may not have standing up.

The encryption keys are the other one to think about before you start, because unlike the database password, an encryption key that is lost is data that is lost. The alovoa.p12 file at the root of the repository is a PKCS12 keystore, and the application.properties file takes the key material. Whatever the exact configuration, the operational rule is the same: the key is your responsibility and it has to be backed up somewhere other than the server.

The debugging guidance is also specific, which is a good sign for a Java project of this size. Spring Tool Suite or IntelliJ is recommended for debugging, and lombok needs to be installed for your IDE, except that it is not needed for IntelliJ, since the IntelliJ plugin handles the annotation processing itself.

The documentation is a single file, DOCUMENTATION.md at the root, and there is a .run/ directory, which is the IntelliJ run configuration directory, so the project ships its own launch profiles for the IDE it recommends.

The Docker path, and a 128 megabyte heap

Docker and Docker Compose are offered as an alternative to the manual setup, and the compose file is the smallest possible working deployment of the application.

It defines two services. The server is built from the local Dockerfile with the context as the current directory, is named alovoa-server, restarts always, publishes port 8081 mapped to the container's 8080, and links to the MariaDB service. The database is mariadb:10.7 with a named volume, its port exposed rather than published, and a database called alovoaDB.

The compose file is not hardened, and that is fine for a development setup. The database credentials are example and example, the user is root, and the database port is exposed to the internal network rather than to the host, which is the one sensible choice in the file. Anyone deploying this should change the credentials and the port mapping, and the server port binding is the thing to look at first, because the application is a public-facing web service by design and the compose file publishes it on the host without any TLS in front of it.

The Dockerfile is a two-stage build that reveals more about the application than the compose file does. The build stage is maven:3.8.6-eclipse-temurin-17-alpine, it copies the pom.xml first and runs mvn verify with --fail-never to warm the dependency cache, then copies the source and runs mvn clean package skipping the tests, so the image builds without needing a database to run the test suite. The runtime stage is a JRE-only image, eclipse-temurin:17.0.6_10-jre, with the built jar copied in.

And then there is the entry point, which is the detail worth reading twice:

ENTRYPOINT ["java", "-XX:+HeapDumpOnOutOfMemoryError", "-Xmx128m", "-jar", "-Dfile.encoding=UTF-8", "-Dspring.profiles.active=prod", "alovoa-1.1.0.jar"]

A 128 megabyte maximum heap, with heap dumps enabled on out of memory errors, and the prod Spring profile active. The heap is small, so this is a deployment tuned for a modest machine, and the heap dump flag is there so that when the heap fills, the evidence is written to disk rather than lost with the process. The jar name is versioned as alovoa-1.1.0 while the project version is 2.0.0, which is a leftover in the Dockerfile and worth noting if you build images yourself.

Three licences in one repository

The licensing section is unusually layered, and the layering is the interesting part for anyone who might reuse the code.

All code is licensed under the AGPLv3 license, unless stated otherwise. All images are proprietary, unless stated otherwise. Third-party web libraries can be found under resources/css/lib and resources/js/lib and have their own license, and third-party Java libraries can be found in the pom.xml and have their own license.

So the code is AGPL-3.0, which means if you run a modified version as a service you owe source to your users. The images are proprietary, which means you cannot lift the photographs and artwork and ship them in your own fork. And the vendored libraries carry their own terms, which is a normal arrangement but one that has to be checked rather than assumed.

The AGPL choice is consistent with the project's stated values. The no-closed-source-libraries commitment and the no-sale-of-data commitment are the same kind of statement, and AGPL is the licence that makes the first one enforceable against a hosted fork.

There is a SECURITY.md at the root and a separate alovoa.p12 keystore, and the licence section points at the third party notices file in the resources. The combination of a security policy, a keystore committed alongside the code, and a strict copyleft licence describes a project that is aware of the sensitivity of the data it holds.

For a deployment, the practical question is what happens to the data of people who used an instance that later goes away. With AGPL and an open source server, a fork is legally possible and technically straightforward, which is a partial answer to that question, though not a complete one.

Maintenance and what the project is asking for

The maintenance picture is modest and the project is candid about it. The last push to the repository was on 2026-05-14, the repository is not archived, and the release list shows v2.0.0 from 2025-01-19, v1.13.0 from 2024-10-10 and v1.11.0 from 2024-05-18, described as minor changes.

So the current major version has been out for over a year and the pushes since then have been on the master branch rather than producing new tags. For a volunteer project that is a reasonable pace, and the presence of a beta.alovoa.com testing site suggests the deployment side is exercised separately from the release tags.

The repository topics include help-wanted, which is a request for contributions, and the README asks for three things: telling people about it, improving it through issues and pull requests, and translating it. That is the same list a project with more engineering help than coding help needs, and it fits a project whose hardest problems are operational, namely running a dating platform responsibly with real people on it, rather than algorithmic.

There is also a scripts/ directory and a hohup.out file at the root, the latter being the log file from a nohup run, which is a small sign of the kind of server this gets deployed on rather than a carefully managed platform.

The one thing the README does not do is explain what a deployment looks like in production terms, such as moderation tooling, abuse handling or the operational side of running a service people meet other people through. Those are the parts of a dating platform that decide whether it works, and they are not in the documentation, so anyone adopting this is adopting the code and the feature list, not a proven operating model.

Editorial conclusion

Adopt Alovoa if you want to run a dating service without a monetisation layer and you are prepared to own the operational side, because the no-ads and no-paid-features position only means something if somebody pays for the hosting and the moderation. Do not adopt it as a base to build a commercial product on, because the AGPL-3.0 on the code and the proprietary images mean you would be redistributing a mixture whose terms you have to read carefully. Before you deploy, set the database, email and encryption key credentials in application.properties, and check the memory setting in the container because the shipped entry point runs the JVM with a 128 megabyte heap.

Frequently asked questions

Official sources

1. Alovoa/alovoa on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases