# PowerJob: a Java scheduler that pushes work to your own workers

> PowerJob is an Apache-2.0 job scheduling framework whose server dispatches jobs to worker processes you deploy next to your application code. It is worth a look if you need MapReduce-style fan-out or DAG workflows inside a JVM shop, and easy to rule out if you want a single binary with no database.

**PowerJob/PowerJob** — Enterprise job scheduling middleware with distributed computing ability.

- Repository: https://github.com/PowerJob/PowerJob
- Website: http://www.powerjob.tech/
- Stars: 7,794 · Forks: 1,381
- Language: Java
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/powerjob-powerjob

## The gap PowerJob fills between cron and a message queue

Most Java teams start scheduling with a cron entry or a Spring @Scheduled method, then hit the same wall: the job runs on whichever instance happens to fire, there is no record of whether it succeeded, and retrying means someone reads a log file. PowerJob targets that gap. It is a scheduling server plus a worker library, and the README describes it as "an open-source distributed computing and job scheduling framework which allows developers to easily schedule tasks in their own application." The phrase that matters is "in their own application": the worker runs inside or beside your process, so a scheduled job can call your service beans directly instead of shelling out to a script.

The README lists five applicable scenes, and they map cleanly onto the execution modes. Timed tasks such as allocating coupons at 9 AM use the ordinary stand-alone mode. Broadcast tasks, described as "broadcasting to the cluster to clear logs," run the same processor on every worker node. MapReduce tasks spread one logical job across many workers, which is the feature that separates PowerJob from a plain cron wrapper. Delayed tasks, such as processing overdue orders, are triggered through the OpenAPI instead of a clock. That last one is the design decision worth noticing: scheduling is not only time-driven here, it is also callable, so an order service can enqueue a delayed job at runtime.

The audience is narrower than the feature list suggests. Everything in the repository is Java and Maven, the worker integrates through a Spring Boot starter, and the processor interfaces are Java-first. If your stack is Python or Go, the Shell and Python processor support means you can still run work, but you lose the in-process calling model that makes the framework interesting.

## Server, worker and the four execution modes

The repository is split into modules that make the architecture legible without reading source. powerjob-server is the scheduler and the UI backend. powerjob-worker is the client library you embed. powerjob-worker-agent is a standalone process that can host workers without modifying your application. powerjob-remote handles the transport between them, powerjob-common holds shared types, and powerjob-official-processors ships ready-made processors. powerjob-client is the OpenAPI entry point.

Scheduling strategy and execution mode are separate axes, and conflating them is a common source of confusion. The README names four timing strategies: CRON expression, fixed rate, fixed delay, and OpenAPI, the last letting you "define your own scheduling policies, such as delaying execution." Separately it names four execution modes: stand-alone, broadcast, Map and MapReduce. A job therefore has one of each. You might run a CRON-triggered job in broadcast mode every night, or an OpenAPI-triggered job in MapReduce mode on demand.

Workflow support adds a DAG layer above individual jobs. The README states that "both job dependency management and data communications between jobs are supported," so a downstream job can consume output from an upstream one rather than polling a table. Retry policy is configurable, and the README frames it in terms of capacity: "As long as there are enough computing nodes, configurable retry policies make it possible for your task to be executed and finished successfully." That is an honest framing and also a constraint. Retries consume worker slots, so a retry storm on a small cluster degrades the jobs that were succeeding.

## Installing PowerJob with docker-compose

The repository ships a docker-compose.yml at the top level, and its own header comment gives the procedure: run `docker-compose up` from the PowerJob root directory, then wait for services to start. The compose file defines three services: powerjob-mysql, powerjob-server, and powerjob-worker-samples.

The MySQL service uses the image powerjob/powerjob-mysql:latest, maps host port 3307 to container 3306, persists data under ./powerjob-data/powerjob-mysql, and starts with --lower_case_table_names=1. The root password in the file is No1Bug2Please3!, which is a development credential and should not survive contact with a shared environment.

```bash
# from the PowerJob root directory
docker-compose up
```

The server service depends on MySQL and exposes four ports. The compose file maps 7700, 10086, 10010 and 10077 to the same numbers on the host. It also sets two environment variables that are worth reading before you change anything: JVMOPTIONS is "-Xmx512m", and PARAMS carries the Spring datasource URL plus a flag disabling MongoDB.

```yaml
environment:
  JVMOPTIONS: "-Xmx512m"
  PARAMS: "--oms.mongodb.enable=false --spring.datasource.core.jdbc-url=jdbc:mysql://powerjob-mysql:3306/powerjob-daily?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai"
```

The worker-samples service is the third piece and the one that shows how a worker finds its server. Its entrypoint waits for powerjob-server:7700 to accept connections before starting the JAR, and passes the server address as a property.

```bash
./wait-for-it.sh powerjob-server:7700 --strict -- java -Xmx512m -jar /powerjob-worker-samples.jar --powerjob.worker.server-address=powerjob-server:7700
```

That property, powerjob.worker.server-address, is the single setting most first-time deployments get wrong. The compose file also carries a commented-out environment block for the same variable, which suggests the address is normally supplied through configuration rather than the command line. For a first real use, the README points at an online trial instance at try.powerjob.tech with the app name powerjob-agent-test and password 123, and recommends reading the trial documentation before poking at it. The trial is the fastest way to see the UI and the execution modes without standing up MySQL locally.

## Where PowerJob is the wrong choice

The dependency footprint is the first real cost. PowerJob needs a relational database for its core state, and the shipped compose file wires in MySQL. There is no documented single-binary mode where the scheduler runs with embedded storage, so a team that wants one process and no database is looking at the wrong tool. The PARAMS line disabling MongoDB shows the project has supported more than one storage backend, but the compose default is MySQL and that is what a new deployment will run.

Operational surface is the second cost. A working deployment is a database, a server, and at least one worker, spread across four exposed ports. The README claims "unlimited horizontal expansion" and high availability through deploying more server and worker nodes, which is true of the design and also means you now own a distributed system's failure modes. If your actual requirement is one nightly batch job, that trade is bad.

The documentation is thin in specific places. The README gives no rollback procedure, no upgrade path between server versions, and no schema migration guidance, so an upgrade from v5.1.0 to v5.1.2 is not something the README tells you how to perform safely. Version compatibility between server and worker is likewise not stated. The README also does not document what happens to in-flight jobs when a server node is lost, beyond the general retry policy claim.

Finally, the language boundary. Processors can be written in Java, Shell and Python, and the README says multilingual scheduling via HTTP will be supported subsequently. That word "subsequently" means HTTP-based scheduling is not available today. If your team writes Go and wants typed, in-process job handlers, PowerJob will not give you that.

## PowerJob compared with XXL-JOB and ElasticJob

The comparison people actually search for is PowerJob versus XXL-JOB, and both appear in the related search data alongside ElasticJob, SnailJob, Dkron and JobRunner. The meaningful difference is the execution model, not the feature checklist.

XXL-JOB is the closest neighbor: a Java scheduler with a server, an executor, and a UI. Its execution model centers on dispatching a job to one registered executor, with routing strategies deciding which one. PowerJob's README puts broadcast and MapReduce on equal footing with stand-alone execution, and MapReduce mode is where "distributed computing resource could be utilized." If your work is naturally divisible, splitting one job across many workers is a first-class operation in PowerJob rather than something you build on top.

ElasticJob takes a different route again. It is a lightweight library that embeds in your application and relies on ZooKeeper or a similar coordinator for sharding, rather than a central scheduling server with its own UI and database. That means less infrastructure to run and less visibility out of the box. PowerJob's trade is the opposite: more moving parts, and in exchange a UI where you manage tasks, monitor status, and read logs online, plus a DAG workflow layer that neither of the other two describes in the same terms.

Dkron sits outside the JVM world entirely and is usually reached for when the scheduler should be a small standalone service. If that is your preference, PowerJob's server-plus-database-plus-worker topology is the wrong shape, and the honest answer is that the two projects are not competing for the same deployment.

## Licence, release cadence and what an upgrade costs

PowerJob is released under Apache License 2.0, and the repository carries a LICENSE file at the top level. Apache-2.0 is a permissive licence with an explicit patent grant and no copyleft obligation on your own code, which is why it is common for infrastructure middleware. This is a description of the licence text, not legal advice; if you redistribute PowerJob or embed it in a product, read the LICENSE file and your own counsel's guidance.

The release record is uneven. Three recent releases are listed: v5.1.0 on 2024-08-11, v5.1.1 on 2024-12-07, and v5.1.2 on 2025-08-17. That is roughly one release every four to eight months, with the gap between v5.1.1 and v5.1.2 being the longest at about eight months. The repository is not archived, and the last push to master was on 2026-03-07, so there is activity between releases, but the tagged artifacts move slowly.

That cadence shapes upgrade cost. Because the README documents no migration or rollback procedure, moving between v5.1.x versions means reading the release notes for each version and testing against a copy of the database first. The docker-compose.yml header comment still references V4.3.1, which tells you the compose file has not been refreshed in step with the 5.x releases. Treat it as a starting point rather than a supported deployment artifact, and expect to change the image tags, the credentials, and the port mappings before it is production-appropriate.

## Conclusion

Adopt PowerJob if your team is already on the JVM and you need broadcast or MapReduce execution modes and DAG dependencies that a plain cron wrapper will not give you. Do not adopt it if you want a single self-contained binary or you cannot operate a MySQL instance alongside a scheduler. Before committing, verify four things: that the server ports 7700, 10086, 10010 and 10077 are free or remappable in your environment, that the worker agent can reach the server address you configure, that the MongoDB path is genuinely optional for your deployment because the compose file disables it with --oms.mongodb.enable=false, and that the processor language you need is among Java, Shell and Python, since HTTP-based multilingual scheduling is described in the README as planned rather than shipped.

## FAQ

### What is PowerJob?

PowerJob is an open-source distributed computing and job scheduling framework that lets developers schedule tasks inside their own application, released under Apache License 2.0. It ships a scheduling server, a Java worker library, and a worker agent, plus a front-end UI for managing tasks and reading logs.

### How does PowerJob compare with XXL-JOB?

Both are Java schedulers with a server and a UI, but PowerJob treats broadcast and MapReduce execution as first-class modes alongside stand-alone execution, and adds DAG workflow support with dependency management and data communication between jobs. XXL-JOB's model centers on dispatching a job to one registered executor with routing strategies deciding which one.

### What does a job scheduler do?

A job scheduler decides when work runs and where it runs, then records the outcome. In PowerJob specifically, the timing side offers four strategies (CRON expression, fixed rate, fixed delay and OpenAPI) while the placement side offers four execution modes (stand-alone, broadcast, Map and MapReduce).

## Sources

- [License: Apache-2.0](https://github.com/PowerJob/PowerJob/blob/master/LICENSE)
- [PowerJob/PowerJob on GitHub](https://github.com/PowerJob/PowerJob)
- [Project website](http://www.powerjob.tech/)
- [README](https://github.com/PowerJob/PowerJob/blob/master/README.md)
- [Releases](https://github.com/PowerJob/PowerJob/releases)

---

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