Plutomi is a multi-tenant applicant tracking system that streamlines your entire application process with automated workflows at any scale.
Having worked at a company that needed to recruit thousands of contractors every month, improving our acquisition flow at that scale became a challenge. Many processes had to be done manually because there just wasn't an API available for it. We often hit limits and had to work around them with a myriad of webhooks, queues, and batch jobs to keep things running smoothly. It would have benefited us to have an open platform to contribute to and build upon and this project is my attempt to do just that.
You can create applications which people can apply to. An application can be anything from a job, a location for a delivery company, or a program like a summer camp.
In these applications, you can create stages which are individual steps that need to be completed by your applicants. You can add questions and setup automatic move rules that determine where applicants go next depending on their responses or after a certain time period.
An application for a delivery company might look like this:
New York City
Stages:
- Questionnaire - Collect basic information of an applicant. If an applicant does not complete this stage in 30 days, move them to the Waiting List.
- Waiting List - An idle pool of applicants
- Document Upload - Collect an applicant's license
- Final Review - Manually review an applicant's license for compliance
- Ready to Drive - Applicants that have completed your application
- Node 20
- Rust
- Docker
- Docker Compose - For local development
- AWS CDK CLI and SSO
Plutomi is deployed to any VPS you can get your hands on (we recommend Hetzner). The frontend is a Remix app and the API is written in Rust using the Axum web framework. We use Traefik as ingress with cert-manager + Let's Encrypt for TLS certificates. We use MongoDB for our main transactional database and try to follow patterns like this where we store everything in a single collection. We use NATS + Jetstream as a message broker for async events.
We use AWS CDK to deploy a couple of resources like setting up SES for emails, SNS to receive email events like opens, clicks, bounces, etc., and a queue to put those events in.
We also use Cloudflare for DNS, CDN, WAF and R2 for storage, and Axiom for logging although this is optional.
We plan to add:
- An events consumer to process NATS and SQS messages
- MeiliSearch for full text search
- ClickHouse for analytics
Simply make a copy of .env.example to a .env file and run ./scripts/run.sh. This will:
-
Setup MongoDB
-
Setup NATS + Jetstream
Credentials for all datasources when testing locally are
adminandpassword. The NATS server will be created with asysuser to manage it, and anadminuser for creating streams & publishing/subscribing to messages. You can create a NATS context to switch between them easily:
$ nats context add admin --server nats://localhost:4222 --user admin --password "password" --description "Admin user" --select-
Start the Web app in development mode on port 3000
-
Start the API on port 8080
- Because the majority of our backend is in Rust, and due to the infamous compile times of Rust, we are running them outside of Docker
- The API along with the events consumer will run with
cargo watchwhich might take some time to initially start but will have hot reloading after that
You can also run any stack individually:
$ ./scripts/run.sh --stack <web|api|datasources>If you decide to run any of the Rust services in Docker, make sure you run them from the /services directory and pass the service Dockerfile as context as we need the /shared library to be included:
# Running the API example in /services
docker build -t plutomi/api:latest-local -f api/Dockerfile . && \
docker run -p 8080:8080 plutomi/api:latest-localTo deploy Plutomi, you'll want to deploy to AWS for setting up SES first and then the rest of the backend with Kubernetes (K3S). Check out DEPLOYING.md for more information.
This project is licensed under the Apache 2.0 license. Here is a TLDR.
See CONTRIBUTING.md
Some common issues you might run into are documented in TROUBLESHOOTING.md, be sure to look there first :)
If you're wondering why certain architectural decisions were made, check the decisions folder as you might find it in there.
If you have any other questions, open a discussion / issue and we can talk about it or reach out to me on Twitter @notjoswayski or email jose@plutomi.com!