Aerospike Server Build and Configuration Guide

What Aerospike Server Is Responsible For

Aerospike Server implements the database server described as distributed, scalable, and flash-optimized. Its stated objectives address web-scale application capacity, the ACID expectations associated with traditional databases, and operation with minimal manual intervention. These are project objectives, not a complete account of the consistency, durability, or availability configuration used by every cluster.

The repository is aimed primarily at engineers who will compile, package, configure, or integrate the server. It is not a client library and does not present itself as a separate administration panel. The source tree is written mostly in ANSI C99, with C++ used for geospatial indexing through Google's S2 Geometry Library and for YAML and JSON configuration parsing.

Aerospike supports traditional `.conf` files and experimental YAML. This distinction matters during evaluation because the README says YAML must be started with a feature flag and validated against a schema. The repository also contains `apidocs/`, `tools/`, `cf/`, and deployment-oriented directories, but the README does not describe their complete runtime architecture. It does not document the partitioning, replication, client protocol, clustering, or storage internals in enough detail to infer those mechanisms from the repository description alone. Claims about those areas require additional Aerospike documentation rather than inference from this source tree.

Why the Submodules Are Part of the Build

A plain source download is insufficient for the documented build. The build graph depends on submodules for JSON handling, memory allocation, Lua, backtraces, geometry, schema validation, configuration parsing, and shared Aerospike code. Git must therefore populate the `modules` tree before compilation.

The dependency list gives each submodule a concrete role. `jansson` and `json` cover different JSON-processing paths, while `jsonschema` validates configuration. `yamlcpp` parses YAML, and `abseil-cpp` supports the S2 geometry library used by geospatial indexing. `jemalloc` supplies the memory allocator, `lua` and `mod-lua` supply the Lua runtime and its Aerospike interface, and `common` provides the Aerospike Common Library.

This is the clearest architectural signal in the available repository structure. Aerospike is not represented as one self-contained C translation unit. Its build composes the server with several separately versioned libraries, including native C and C++ dependencies. That makes submodule revisions part of release integrity rather than an optional development convenience. The README also warns that a GitHub `Download ZIP` archive will not build unless each submodule is manually installed at the correct revision under `modules`. Such a ZIP workflow is therefore the wrong path for a reproducible source build.

Building Aerospike on a Supported GNU/Linux Stack

The README names Red Hat Enterprise Linux 8/9, Amazon Linux 2023, Debian 11 or later, and Ubuntu 20.04 or later as examples of supported 64-bit GNU/Linux environments. A C++ compiler is required even for users who do not intend to enable geospatial indexing, because the build includes the S2 and C++ configuration components.

Start from a Git clone with submodule support, then install the documented development dependencies. The repository's script performs that installation:

./bin/install-dependencies.sh

After cloning, fetch the pinned submodule revisions before invoking the build:

git submodule update --init

The default target compiles the server without producing a package:

make

On a multi-core build host, the documented parallel form is:

make -j4

The root `Makefile` delegates the main server build to the `as` subdirectory after preparing libraries including Jansson, JEMalloc, libbacktrace, Common, the client feature directory target, S2, JSON parsing, schema validation, and YAML parsing. Successful completion should leave a built server tree suitable for the subsequent configuration and startup process. The README does not provide a minimal client write-and-read demonstration, so the first verifiable operation at this stage is compilation rather than an invented application test.

Choosing a Makefile Output for Deployment

Aerospike offers an unpackaged build and two distribution-package targets. The default build is useful when the host packaging system is not the intended delivery method. Package targets are closer to a conventional Linux installation workflow because the repository labels them specifically for supported distributions.

The available Makefile targets are:

make deb
make rpm
make source

`make deb` creates a Debian or Ubuntu package, while `make rpm` creates an RPM package for Red Hat-derived systems. `make source` produces a compressed source archive. These commands are packaging operations layered on the normal build, rather than alternative compiler configurations.

This creates a real deployment trade-off. Building with `make` gives an engineer the server build directly from the repository. Building with `make deb` or `make rpm` shifts part of the work into a distribution package that can be managed separately from the source checkout. The README does not state the package output locations, signing policy, service unit behavior, or upgrade hooks, so those details should not be assumed before inspecting the generated artifacts.

Clean-up is explicit. `make clean` preserves packages, `make cleanpkg` removes packages, `make cleanall` removes both build products and packages, and `make cleangit` deletes every file untracked by Git. The last target carries a caution because its scope extends beyond ordinary compiled output.

Selecting .conf or Experimental YAML Configuration

Traditional `.conf` is the established path in this repository. Sample files are stored under `as/etc`. The README distinguishes `aerospike_dev.conf`, described as a developer configuration with basic out-of-box settings, from `aerospike.conf` and `aerospike_ssd.conf`, which are described as package examples suitable for running the server as a system daemon.

YAML configuration is explicitly experimental. It uses JSON schema validation and must be enabled with `--experimental`. The server can optionally receive a replacement schema through `--schema-file <file>`, while the default schema location is `/opt/aerospike/schema/aerospike_config_schema.json`. At startup, the schema validates the supplied YAML and is intended to report configuration errors early.

The `asconfig` tool does not generate YAML that can be passed to this experimental server path without manual changes. According to the README, it currently emits an older format. Migration requires converting arrays to maps, removing entry-level `name` fields because map keys carry those names, and restructuring logging sinks with typed `contexts` values. File and syslog sinks also have additional fields described in the schema. This migration burden makes YAML a poor first choice for an operator who needs a known starting point, especially because the README does not provide a complete converted example.

Licence, Maintenance, and Upgrade Boundaries

GitHub classifies the repository licence as Other, and the repository contains `LICENSE`, `LICENSE-AGPL`, `LICENSE-APACHE`, and `LICENSE.3rdParty`. The README does not explain how those files apply to server code, bundled submodules, generated packages, or a deployed service. Any legal interpretation would therefore exceed the available documentation. An engineering review should inspect the exact licence files for the revision being built, including submodule licensing.

The repository is not archived, and the last push was on 2026-10-07. Recent release entries include 8.2.0.0 on 2026-10-07, 8.1.2.5 on 2026-09-21, and 8.1.2.4 on 2026-09-23. These dates indicate recent repository activity, but they do not remove the upgrade work associated with a C server with numerous native dependencies and pinned submodules.

The documented upgrade boundary is not a one-command path. A source adopter must account for submodule revisions, configuration conversion where relevant, package formats, startup options, and the distinction between development and daemon-oriented sample files. The README does not document rollback, in-place server upgrades, mixed-version clusters, backup procedures, or compatibility between adjacent releases. Those omissions should be resolved against the release documentation before changing a running database.

Editorial conclusion

Adopt Aerospike Server when the application specifically requires Aerospike and the deployment environment matches one of the documented GNU/Linux platforms. Do not choose it merely because the README uses the terms in-memory or ACID, since the source build alone does not establish a complete production deployment. Before adoption, verify the intended package or binary, `aerospike.conf` settings, licence obligations, service startup path, and whether experimental YAML configuration fits the operational process.

Frequently asked questions

Official sources

1. aerospike/aerospike-server on GitHub
2. Issues
3. Project website
4. README
5. Releases