activist, an open source platform for organising campaigns and events

What the platform is for

activist is described as a platform that makes it easy and safe to engage in activism, to discover organizations and events, and to coordinate and collaborate on political action. The stated mission is to help activists connect and share strategies for social and ecological change, and the goal is a global platform where movements grow and people are inspired to join in political action.

The mission statement goes further, saying the project wants to change how power is distributed in society by removing barriers and enabling more people to safely engage in activism. That word safely is doing work, because the features list is full of things that reduce the risk of participation rather than things that broadcast positions.

The four properties the README gives are Free, Open-source, Privacy-focused and Governed by our community. The privacy claim has supporting evidence in the repository rather than only in the marketing: there is a PRIVACY.txt at the top level, a NOTICE.txt, and the resource feature is described as private by default with an option to make items public.

The topics the platform organises content around are listed in a table: Accessibility and Inclusion, Animal Rights, Democracy and Governance, Education, Emergency Relief, Environment, Health, Housing, Labor Rights, LGBTQIA+, Peace and Resolution, Racial Justice, Refugees and Migration, Technology and Privacy, and Women's Rights. Tags are used for more specific issues within those topics, so there are two levels of classification.

The licence is AGPL-3.0, the primary language is TypeScript, and the site is activist.org. The last push was on 2026-10-19.

One thing to understand about the model is that this is a platform for organisations and their campaigns, not a general social network. The unit of the data model is an organisation, a group and an event, which is a different shape from a platform where the unit is a person.

The three feature areas and what each one does

The README describes the planned feature set in three areas, and the project board is where the work is tracked.

Organisation profiles are described as easy-to-use microsites with multiple subpages, for organisations of all sizes. The four capabilities listed are describing the organisational structure and goals, explaining how the groups collaborate, safely onboarding new team members, and answering frequently asked questions. That last one is not a throwaway: the questions an outsider asks before joining a campaign are the same ones a new volunteer asks, and answering them once on the profile saves every member answering them repeatedly.

Events are the collaborative part, and they come in two types. Learn events cover seminars, meetings and panel discussions. Action events cover protests, volunteering and canvassing. Alongside them there is a feed for organisers to share real-time information with participants, event templates that organisations can create and share with allies, the ability to transform event pages into flyers or posters and link them via QR codes, and legal notes to warn participants of the risks involved.

That last feature is the clearest statement of what the platform is for. Legal risk notes attached to an event page are something a general event platform will not have, and they are exactly what a first-time participant at a protest needs to know.

Resources are described as a simple link hub for organisations, saved under organisations, their working groups and events. They keep important links in one place, are private by default, and can be made public.

The pattern across the three is consistent. Each is scoped to an organisation, a group or an event, and each defaults to a low-visibility posture that the organisation can widen deliberately. Nothing in the design is broadcast-first, which is the opposite of most social platforms and is the point.

The stack and the development environment

The badges in the README give the tech stack, and it is a two-language application with a JavaScript front end and a Python back end.

The back end is Django 5 with FastAPI 1, and the front end is Nuxt 4 with Vue 3 and Tailwind 4. The CONTRIBUTING.md is where the tech stack is documented in detail, which is where a contributor would start.

The local environment is defined by the docker-compose.yml at the repository root. The database service runs postgres:15 with the credentials from the .env.dev file, a named volume so the data survives restarts, a comment on how to reset it explicitly with docker compose --env-file .env.dev down -v, and a healthcheck using pg_isready on a ten second interval with five retries.

The backend service depends on the database being healthy and on the mail service having started, and its command is a shell sequence that shows how the application boots. In development it clears the dev images, then waits for the database, runs makemigrations and migrate, and loads three fixture files: a superuser, the status types and the topics. It then runs a populate_db command with a skip-if-populated flag, with counts for users, organisations per user, groups per organisation, events per organisation, events per group, FAQ entries per entity and resources per entity, and finally applies a YAML file of entity data to assign. Only then does it start the runserver.

That sequence is a good summary of the domain model, because the counts tell you the shape of the graph: users own organisations, organisations contain groups, and both organisations and groups hold events, FAQ entries and resources.

The rest of the repository supports that. There is a reset-dev-db.sh script, a run-e2e-tests.sh script, a pre_commit_scripts/ directory, a utils/ directory, a services/ directory, and separate backend/ and frontend/ directories. There are also BACKEND_TESTING.md, FRONTEND_TESTING.md and LOCALIZATION.md as separate documents, and a STYLEGUIDE.md, which tells you the project treats its conventions as something to write down rather than assume.

The CI configuration is visible in the badges. There are separate workflows for backend pytest, backend static analysis, frontend vitest, and end-to-end tests with Playwright on both desktop and mobile, which is a thorough matrix for a project of this size.

Localisation, hosting and what to weigh before adopting

Two things stand out in the project infrastructure and both matter for an activist organisation.

The first is translation. There is a Weblate badge pointing at a hosted project, a LOCALIZATION.md document, an .i18n-check.yaml configuration in the repository root, and a NOTICE.txt. For a platform whose audience spans languages and whose content is written by volunteers in many of them, having translation infrastructure in the repository from the start rather than added later is a real advantage, and the i18n check file suggests the translation keys are enforced in continuous integration rather than left to drift.

The second is the deployment target. The Netlify badge points at the frontend, and the repository has a docs/ directory and a .github directory with issue templates, a pull request template and a CODE_OF_CONDUCT.md, plus a Matrix space for the community.

On the AGPL licence, this is the decision that needs a legal answer before you use it with organisational data. AGPL-3.0 means that if you modify the software and let users interact with it over a network, you must offer those users the corresponding source of your modified version. A group running their own instance for their own members is usually fine with this, because there is no distribution to a third party. A commercial deployment of a modified version is a different question entirely.

The other consideration is the social one. A platform for activism holds membership lists, event locations and the names of people taking part in actions. That is sensitive data about real people, and it is the kind of data that makes an operator a target. The project ships a PRIVACY.txt and a SECURITY.md, which is the right shape, and the resource feature is private by default, but the responsibility for the data still sits with whoever runs the instance.

The honest summary is that this is a well-organised, thoughtfully built platform with a two-language stack and a thorough test matrix, aimed at a specific need that generic social platforms do not serve. Whether it fits depends on whether your organisation wants a presence on someone else's platform or its own, and on the operational appetite that implies.

Editorial conclusion

Adopt activist if you are an activist organisation that wants a maintained, self-hostable web presence with profiles, events and a shared resources area rather than a bespoke site. Skip it if you need a general purpose event platform or a social network, since the data model is built around organisations, groups and campaigns. Verify first by reading the compose file, since the development stack seeds its database with fixture users, organisations and events, and check the AGPL terms with whoever owns your licensing before you put organisational data in it.

Frequently asked questions

Official sources

1. activist-org/activist on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README