vas3k.club ships a paid membership platform that its own members are expected to fork

A community product, not a tutorial site

The repository description calls vas3k.club a platform with private and paid memberships that has emerged around the vas3k.blog blog and satellite chat rooms. The README is blunt about what it is not: it is not a typical IT community with tutorials and framework reviews, but rather more of a lifestyle one. That framing matters for an engineer evaluating it, because the code is shaped by the needs of a small, curated membership rather than by the needs of an open audience. The stated values are honesty, fair share, respect, rationality, friendliness and usefulness, with a zero tolerance policy on anonymity, insults and toxicity, and also a stated intolerance of witch hunting and call-out culture. The code was opensourced so that every member could contribute or implement a feature they want, which makes this a product codebase open to its own user base.

Vue components dropped into Django templates instead of an SPA

The stack is described in a single line as Django, Postgres, Redis, Vue 2, Webpack and uv, with the stated goal of keeping it as simple as possible. The architectural decision is in the frontend. The project does not use a single page application, and instead makes parts of a page dynamic by inserting Vue.js components directly into Django templates. The claimed benefit is that one person can develop and maintain the whole site. The webpack to Django communication is handled for you, django-webpack-loader is in the dependency list, and the development loop is two commands running side by side:

uv run python manage.py runserver
npm run watch --prefix frontend

For native development the Makefile provides matching targets, run-dev which invokes uv run python manage.py runserver 0.0.0.0:8000 and run-queue which invokes uv run python manage.py qcluster.

The Docker Compose stack starts five services, and dev logins for testing

The documented local setup assumes Docker with Docker Compose and nothing else. The clone and startup sequence is three commands:

git clone https://github.com/vas3k/vas3k.club.git
cd vas3k.club
docker compose up --build

The compose file in the repository shows what that brings up: a club_app service built from the local Dockerfile running make docker-run-dev, a queue service running make docker-run-queue, a postgres service on the postgres:14 image, a redis service, and a webpack service. The app service waits for postgres and redis to be healthy and for the queue and webpack to have started before it runs. Startup applies database migrations and initializes the built-in tags, so the site is usable once Django and webpack have finished starting, and the entry point is http://127.0.0.1:8000/. The compose file publishes only port 8000 for the app, and the documentation states that the default Compose file does not publish database or Redis ports for host Python processes.

Two shortcuts make local testing possible without configuring a real membership. The admin login at http://127.0.0.1:8000/godmode/dev_login/ creates or reuses the dev account, and a newly created account has the god role. The random member login at http://127.0.0.1:8000/godmode/random_login/ creates and signs in as a new member each time, which is the fast way to create test content. Both routes are available only in debug or test mode, and the development Compose stack enables debug mode with DEBUG=true in the environment. After signing in as an admin you open /godmode/. The godmode app sits alongside other Django apps in the top level listing, next to users, posts, comments, payments, tickets, rooms, invites, notifications and badges.

Apple Silicon needs amd64 emulation because of Supercronic

There is one platform wrinkle and the documentation handles it explicitly. On ARM machines, including Apple Silicon, the current Dockerfile requires amd64 emulation because it downloads an amd64 Supercronic binary. The alternative command is:

DOCKER_DEFAULT_PLATFORM=linux/amd64 docker compose up --build --pull always

The reason is visible in the Dockerfile, where SUPERCRONIC_URL points at a supercronic-linux-amd64 release and the binary is verified with a pinned SHA1 sum before being moved into /usr/local/bin. So an ARM developer pays emulation cost for the whole image rather than for one component, which is why the override is a platform-wide flag and not a per-service setting. The same Dockerfile is a multi-stage build: a uv python-builder stage that installs build-essential, libgdal-dev and libpq-dev, a node:22-slim frontend-builder stage that runs npm ci and npm run build, and a final python:3.14-slim stage carrying gunicorn, make and the cron binary.

Payments are wired to three providers and one library per case

The payments app is where the commercial side of the platform lives, and the dependency list shows the range of providers it speaks to. stripe is pinned at 11.4.1, yookassa at 3.11.0, patreon at 0.5, and there is a separate typus package at 0.2.2 for a Russian payment system. OpenAI is also a dependency at openai>=2.46.0, along with python-telegram-bot and telethon for the chat and bot integrations, icalendar for calendar export, and premailer and mistune for email and markdown rendering. GDPR handling sits in its own gdpr app, search in a search app, and there are separate directories for gdpr, map, bookmarks, clickers, helpdeskbot and notifications. That breadth is a fair proxy for what a paid community platform involves beyond posts and comments.

Tests run inside the container with a flag, and the CI mirrors it

The test commands assume the development stack is already running, and they set an environment variable to distinguish a test run from a normal shell:

docker compose exec -e TESTS_RUN=true club_app python3 manage.py test payments.tests

The same pattern runs the full backend suite:

docker compose exec -e TESTS_RUN=true club_app python3 manage.py test

The Makefile encodes the same idea for native runs, with test mapped to TESTS_RUN=true uv run python manage.py test and test-frontend moving into the frontend directory to run npm test. Continuous integration runs Flake8, the backend tests and the existing frontend Jest suite, while a separate build check verifies Docker startup and webpack compilation. The guidance on coverage is specific and unusually opinionated: new coverage should focus on important Python behaviour and persisted state, not templates, buttons, CSS or notification wording, and browser checks run only when requested.

Deployment is SSH and a GitHub Actions workflow, not Kubernetes

The deployment section is blunt: no k8s, no AWS, the images ship directly over SSH. Production configuration lives in docker-compose.production.yml, and GitHub Actions run the tests, build the image and deploy on pushes to master or on manual dispatch for maintainers. The production Makefile target runs gunicorn with club.wsgi:application, five workers, a gthread worker class with two threads, bound to 0.0.0.0:8814, with a 60 second timeout and a max-requests setting of 1500 with jitter of 300. The project also asks for proposals on improving deployments without overcomplicating it with modern devops tooling, which tells you where the maintainers want the complexity to sit.

Feature flags are the contract between a fork and the upstream

Forking is a first class use case here, and the project sets expectations about it. The README says forks are welcome and that the engine is not universal like Wordpress, but that with sufficient programming skills and grep you can launch your own Club website in a couple of weeks. Three requests come with that invitation: give kudos to the original authors, keep a footer line saying the site works on the vas3k.club engine, share the features you implement upstream so your codebase diverges minimally, and do not use the issues and chats as a support desk for your own fork. The mechanism that makes minimal divergence possible is the feature flags file at club/features.py, which the documentation describes as the place to create new flags for upstreaming features or disabling existing ones. Practical checklists live in docs/install_checklist.md and docs/tech_guide.md. The licence field on the repository says MIT, and the project publishes no GitHub releases, with the last push on 2026-10-20.

Editorial conclusion

vas3k.club suits a team that wants to run a small paid membership community with real billing, chat and moderation already solved, and that is willing to keep its fork close to the upstream code so security fixes and upstream features can be merged. It does not suit a project that needs a general purpose content platform, multi tenant SaaS, or a front end that expects a single page application, because the design deliberately avoids both. Before you deploy it, read docker-compose.production.yml and docs/install_checklist.md, decide where Stripe, Patreon or YooKassa credentials will come from, and check the Python requirement in pyproject.toml against your host, since the project pins requires-python >=3.14.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vas3k/vas3k.club on GitHub