# ChiefOnboarding: employee onboarding that runs in Slack or a dashboard

> ChiefOnboarding is an AGPLv3 Django application that puts new hire onboarding into a Slack bot and a web dashboard, with sequences, to do items, resources and badges. The code is Python 3.13 on Django, it deploys by Docker or by one click button, and it expects you to host it yourself.

**chiefonboarding/ChiefOnboarding** — Free and open-source employee onboarding platform. Onboard new hires through Slack or the web portal.

- Repository: https://github.com/chiefonboarding/ChiefOnboarding
- Website: https://chiefonboarding.com
- Stars: 932 · Forks: 166
- Language: Python
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/chiefonboarding-chiefonboarding

## Onboarding as a workflow object instead of a checklist in email

Most onboarding software is a form with a due date attached. ChiefOnboarding takes a different shape: onboarding is modelled as a sequence of items that drip out over time, or that unlock when a new hire completes a specific to do. The README describes this as sequences, and frames the goal as avoiding the overwhelming feeling of receiving everything at once. Around that core sit to do items with fillable forms, a resources section where hires search a knowledge base and complete courses, badges that reward completed work, introductions that connect a new hire with colleagues, and admin to do items so that other staff can be assigned preparation tasks. Pre-boarding pages let a hire be welcomed before day 1. The people it is built for are operations and IT teams who keep doing the same twenty steps by hand, and who want the process to run where their hires already are.

## The Slack bot and the dashboard are two front ends on one system

The README states that new hires can use the dashboard or the Slack bot, and that both provide all features and can be used standalone. That framing matters for adoption: some hires will never open a web portal, and a team can run a hybrid without duplicating state. The dependency list in pyproject.toml shows how the Slack side is built, with slack-bolt present alongside Django and Django's REST framework. Everything else in that list is the standard weight of a Django application with background work: psycopg[binary] for Postgres, django-q2 and croniter for scheduled tasks, whitenoise for static files, gunicorn as the application server, and sentry-sdk for error reporting. Communication with people goes through django-anymail and twilio, while django-allauth comes with the mfa and socialaccount extras, and django-axes is there for brute force protection on login. The project also depends on boto3 and cryptography, which points to object storage and secret handling rather than to anything specific to onboarding.

## What the development stack looks like before you deploy anything

The repository root shows a Python 3.13 project, with requires-python set to ~=3.13.0 in pyproject.toml and the application version recorded there as 2.5.0. The project name in that file is ChiefOnboarding, and the tool.uv section sets package = false, which tells you the repository is not itself published to PyPI as a library. The code sits under back/, with docs/, init/ and bin/ alongside it, plus a Procfile for PaaS deploys, app.json, render.yaml and a makefile. For local work the docker-compose.yml defines three services on a shared network: a Postgres database, a web service, and an aws service running ministackorg/ministack:1.4.16 with SERVICES: s3 for local object storage. The web service builds from ./Dockerfile-dev with the context set to ./back/, mounts ./back into /app, reads its environment from a .env file through env_file, and publishes only on localhost:

```yaml
  web:
    restart: always
    build:
      dockerfile: ./Dockerfile-dev
      context: ./back/
    ports:
      - "127.0.0.1:8000:8000"
    env_file:
      - .env
```

The Postgres service in the same file exposes 5432 and sets POSTGRES_PASSWORD to postgres, and the aws service maps 4566 for the S3 emulator. Those are development defaults. If you plan to run this in production, the compose file is the wrong artefact to copy.

## One click deployment buttons versus hosting it yourself

ChiefOnboarding can be hosted on your own infrastructure or run by the vendor, and the README lists a long set of deployment routes. Docker images are published at ChiefOnboarding on Docker Hub, and the project carries deploy buttons for Heroku, Render, Elestio and Easypanel. The ZopDay button points at an image with the tag chiefonboarding/chiefonboarding:latest and a port of 8000. Full details live in the documentation at docs.chiefonboarding.com, with a separate integrations site listing the available connectors. The feature list ties into this: the platform can automatically provision user accounts and trigger webhooks, and the README says you can create your own integration rather than being limited to the listed ones. For a team that already runs containers, the Docker route with your own Postgres and your own secrets is the more predictable one. For a team without platform staff, the hosted option removes the backup and upgrade burden that the README mentions, at the cost of the AGPL source obligation staying in the vendor's hands.

## Customisation, languages and timezones are the differentiators

Three of the README's features point at a specific audience: multilingual support, per hire timezones, and the claim that nobody will know you are using ChiefOnboarding. The supported languages listed are English, Dutch, Portuguese, German, Turkish, French, Spanish and Japanese, with a request to email the maintainers for another one. The timezone setting exists so a remote hire is not messaged in the middle of the night, which is a problem most general purpose task tools have because their reminder engine knows nothing about the person it is reminding. Customisation covers the logo, the colour scheme, the email template and the bot itself. Customizable does not mean fork free, though. ChiefOnboarding is licensed under AGPLv3, a strong copyleft licence, and the README is explicit that the project is completely open source under that licence. If you intend to modify it and run it as a network service, the terms in LICENSE.md need a legal reading before you commit to that plan.

## Support is a GitHub issue unless you pay for it

The README is blunt about support: the software is provided under an open source licence and comes as is, questions go to GitHub issues, and guaranteed quick support is offered as a paid package with a best effort target of generally under two hours response time. That framing is honest and it shapes the decision. Running this in-house means you own Postgres backups, the Slack app credentials, the upgrade path between versions and the incident response. The release history shows the pace of that upgrade path, with v2.5.0 published on 2026-09-10, v2.4.0 on 2026-02-24 and v2.3.1 on 2025-10-11. The repository is not archived and the last push was on 2026-10-20, so the code is moving. Security issues have their own channel, security@chiefonboarding.com, and the README asks that potential vulnerabilities not be filed as public issues. The repository also carries a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a CHANGELOG.md, so the usual governance files are in place for a self hosted deployment.

## The alternative: scripts, a form and a scheduler

The honest alternative to ChiefOnboarding is not another onboarding product, it is the stack many teams already have. A shared task list or form tool can hold the to dos, a scheduled job can send the reminders, a wiki holds the resources and a small script posts to the Slack API. The difference in approach is that this DIY version has no concept of a new hire as a record with a start date, a language and a timezone, so the things ChiefOnboarding does well, per hire timezones, drip sequences, badges and pre-boarding pages, all have to be built and then maintained as your own code. What ChiefOnboarding adds is a data model, a Slack bot and the integrations that provision accounts. What it costs is a Django application, a Postgres database, background workers and the AGPLv3 obligation. For a company with twenty hires a year and a simple checklist, the DIY version is cheaper and simpler. For a company onboarding many people across many languages on an existing infrastructure, the data model is the thing worth paying for.

## Conclusion

ChiefOnboarding suits companies with a real onboarding process that wants it visible in Slack and owned by their own infrastructure, and it removes the spreadsheet and email reminders that usually stand in for one. Skip it if you only need a shared checklist, because the Django application, Postgres service and Slack bot are a lot of surface to run. Before adopting, read LICENSE.md with your legal reviewer given the AGPLv3 terms, work through the docker-compose.yml in the repository, which is built for development rather than production, and confirm the Slack app permissions the bot needs before you migrate real hire data.

## FAQ

### What is ChiefOnboarding and what does it replace?

ChiefOnboarding is a free and open source employee onboarding platform, licensed under AGPLv3, that runs new hire onboarding through a Slack bot or a web dashboard. It replaces the checklists, reminder emails and wiki pages a team assembles by hand.

### How do I run ChiefOnboarding locally?

The repository ships a docker-compose.yml that starts a Postgres service, a web service built from ./Dockerfile-dev and a ministack S3 emulator, with the web service publishing on 127.0.0.1:8000 and reading configuration from a .env file. The project requires Python ~=3.13.0.

### Does ChiefOnboarding work with Slack only, or do I need the web dashboard?

The README states that new hires can use the dashboard or the Slack bot, and that both provide all features and can be used standalone. The Slack integration is built on slack-bolt.

### What licence is ChiefOnboarding released under?

AGPLv3, with the terms in LICENSE.md at the root of the repository. The README states the project is completely open source and licensed under AGPLv3, which matters if you plan to modify it and offer it over a network.

### How is ChiefOnboarding updated and who do I contact for support?

The last push was on 2026-10-20, with v2.5.0 released on 2026-09-10 and v2.4.0 on 2026-02-24. The README says support questions go to GitHub issues, with a paid package offering a best effort response generally under two hours, and security issues go to security@chiefonboarding.com.

## Sources

- [chiefonboarding/ChiefOnboarding on GitHub](https://github.com/chiefonboarding/ChiefOnboarding)
- [License: AGPL-3.0](https://github.com/chiefonboarding/ChiefOnboarding/blob/master/LICENSE)
- [Project website](https://chiefonboarding.com)
- [README](https://github.com/chiefonboarding/ChiefOnboarding/blob/master/README.md)
- [Releases](https://github.com/chiefonboarding/ChiefOnboarding/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chiefonboarding-chiefonboarding