ApolloAuto/apollo: what the open autonomous driving platform actually gives you

What Apollo solves, and who it is actually for

Apollo targets a narrow audience: teams that already own a vehicle with brake-by-wire, steering-by-wire, throttle-by-wire and shift-by-wire, and that need a full software stack rather than a single algorithm. The README states Apollo is tested on a Lincoln MKZ, which tells you the reference integration is a specific production car and not a generic robotics platform. If you are building a sidewalk robot, a warehouse AGV or a simulation-only research project, the hardware prerequisites alone rule you out.

The project bundles perception, planning and control modules under a common build system and a common runtime. It is not a library you call from your own program. It is closer to a distribution: you build the whole tree, start a container, and run modules that talk to each other over a message bus. That shape is the reason the README spends most of its length on prerequisites and version history instead of API documentation. The unit of adoption is a vehicle, not a dependency.

The version ladder is the architecture documentation

Apollo does not present itself as one product. The README describes each release as a scope: 1.0 is Automatic GPS Waypoint Following for enclosed venues such as a test track or parking lot; 1.5 adds LiDAR for fixed lane cruising; 2.0 handles simple urban roads with traffic light stops and lane changes; 2.5 runs on geo-fenced highways with a camera for obstacle detection; 3.0 targets closed venues at low speed; 3.5 adds 360-degree visibility and scenario-based planning for unprotected turns and narrow residential streets.

The README explicitly recommends installing versions in order, starting at 1.0 and moving up, so that individual hardware components and modules can be confirmed working before you attempt a more capable version. That is an unusual instruction for a software project and it reveals the real dependency graph: the hard part is the vehicle interface, not the code. A team that jumps straight to a newer release inherits unverified wiring, unverified calibration and unverified actuators at the same time as unfamiliar software. The ladder is a debugging strategy.

Recent releases listed in the repository are v9.0.0 in December 2023, v8.0.0 in December 2022 and v7.0.0 in December 2021, so the tagged cadence is roughly annual.

Installing Apollo and running the first container build

The README does not give a package manager install. It gives a container workflow. Before any of it, the host needs Ubuntu 18.04, 20.04 or 22.04, Docker-CE 19.03 or above, the NVIDIA Container Toolkit, an NVIDIA driver at 520.61.05 or above (or ROCm v5.1 and above), an 8-core processor with 16GB of memory minimum, and a Turing-class NVIDIA GPU or an AMD GFX9/RDNA/CDNA GPU. The README states NVIDIA Turing or AMD GFX9/RDNA/CDNA is strongly recommended rather than strictly mandatory, but the CUDA 11.8 upgrade described in the November 2024 prerequisites exists to support Ada Lovelace 40x0 series cards.

If you are migrating from an older build, the README gives these two steps. The first removes stale Bazel output, and the second restarts the development container.

rm -rf /apollo/.cache/{bazel,build,repos}

./docker/scripts/dev_start.sh

After the container is running, the repository root contains apollo.sh, the build and run entry script, alongside the Bazel WORKSPACE file and the modules directory. The README points readers to the Quick Starts and Documents sections for the per-version launch procedures rather than listing a single canonical run command, so the first real use depends on which version you are bringing up. Expect the first meaningful milestone to be a module starting inside the container, not a car moving.

Where Apollo is the wrong tool

The prerequisites are the limitation. Apollo assumes by-wire control of brakes, steering, throttle and shift. Without that, the control modules have nothing to command, and the perception and planning layers become an expensive way to visualize sensor data. The README also notes that Apollo 2.5 testing should be done with the help of the Apollo Engineering team, which is a candid admission that not every version is self-service.

Hardware support is another boundary. The GPU list is specific: NVIDIA Turing or newer, or AMD GFX9/RDNA/CDNA. An older card or an integrated GPU leaves you outside the documented path. LibTorch is pinned differently per architecture, version 1.11.0 for arm64 and 1.7.0 for x86_64, so the two platforms are not on the same inference stack.

Finally, the repository is not a drop-in planning library. There is no documented Python API for calling the planner from your own code, and the README's framing is deployment, testing and calibration of vehicles. If your goal is to benchmark a trajectory optimizer against recorded logs, the build and container overhead is a poor trade.

How Apollo differs from Autoware

Autoware is the closest open comparison in this space, and the difference is in how the two projects present themselves. Apollo's README organizes everything around numbered releases with declared driving scopes, from GPS waypoint following in a parking lot up to scenario-based urban planning, and it tells you to climb that ladder in order. The project's identity is a sequence of validated vehicle integrations.

Apollo also carries its own middleware, cyber/, in the repository root, rather than assuming ROS. That choice shows up in the build: Bazel plus the WORKSPACE file plus apollo.sh, with a Docker development container as the supported environment. A ROS-based stack lets you mix and match community packages; Apollo gives you a more closed, more vertically integrated tree where the message transport, the modules and the build are maintained together.

Neither approach is free. Apollo's integration means fewer moving parts to reconcile, and less freedom to substitute a component you prefer. If you want to swap in your own planner, a ROS-based stack is the easier host. If you want a stack whose pieces were built to run together on a specific car, Apollo's structure is the argument.

Maintenance, licensing and the upgrade bill

The last push to the default branch was on 2026-04-16, and the repository is not archived. The most recent tagged release is v9.0.0 from 2023-12-18, so the tags lag the branch. Treat the branch as the moving target and the release tags as the stable reference points.

Upgrade cost is documented and it is not trivial. The November 2024 prerequisites note that CUDA moved to 11.8, that the host NVIDIA driver must be at 520.61.05 or above, and that LibTorch for arm64 moved to 1.11.0 while x86_64 stayed at 1.7.0. The migration steps are removing the Bazel cache and restarting the dev container, which means a full rebuild of the tree. On an 8-core machine that is a real time cost, and it recurs whenever the pinned CUDA or LibTorch versions move.

Licensing is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms. The repository does not document a separate model or dataset licence in the files reviewed here, so if you plan to redistribute anything beyond the code, check the individual files under modules/ and third_party/ rather than assuming the top-level LICENSE covers them. That is a question for your own counsel, not something the README answers.

Editorial conclusion

Adopt Apollo if you have a by-wire vehicle, a supported Ubuntu host and the patience to work through the version ladder from 1.0 upward, because the platform is built around hardware calibration rather than simulation alone. Do not adopt it if you want a pip-installable planning library or you have no vehicle to calibrate against. Verify first that your NVIDIA driver is at 520.61.05 or above, that your GPU is Turing or newer, and that you can run ./docker/scripts/dev_start.sh and build inside the container before you commit to the stack.

Frequently asked questions

Official sources

1. ApolloAuto/apollo on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases