# Instance configuration

Know which services and listeners your deployment actually exposes.

Source: https://docs.minds.sh/docs/operations/configuration



Akasha configuration determines which routes are registered and which services can run. A feature described in the engine reference can be absent from a particular deployment if its service was not enabled.

## Core configuration [#core-configuration]

| Setting                 | Purpose                   | Source default                  |
| ----------------------- | ------------------------- | ------------------------------- |
| `AKASHA_HTTP_ADDR`      | HTTP listener             | `0.0.0.0:8080`                  |
| `AKASHA_ROUTER_ADDR`    | Router listener           | `0.0.0.0:50051`                 |
| `AKASHA_GRPC_ADDR`      | gRPC listener             | `0.0.0.0:50053`                 |
| `AKASHA_FLIGHT_ADDR`    | Arrow Flight listener     | `0.0.0.0:50054`                 |
| `AKASHA_CONDUCTOR_ADDR` | Conductor listener        | `0.0.0.0:8082`                  |
| `AKASHA_DATA_DIR`       | Persistent data directory | `./akasha_data`                 |
| `AKASHA_REQ_MAX_BYTES`  | HTTP request-size limit   | `10000000`                      |
| `AKASHA_SERVICES`       | Startup service groups    | Full configuration when omitted |

These are daemon defaults, not recommended public network exposure or hosted endpoint addresses. Bind only the interfaces you intend to serve and apply the deployment's network and transport controls. In particular, the current gRPC and Flight authority gaps require private listener treatment until fixed and verified.

## Full engine and service groups [#full-engine-and-service-groups]

The current startup parser includes `kv`, `graph`, `analytics`, `ml`, `inference`, `vector`, `memory`, `cognitive`, `cognitive-cycle`, `mcp`, and `all`. `all` or `cognitive` enables the full configuration. Some families, including SNN and associative memory, do not have their own independent startup group in this snapshot.

Both Free and Pro have the same full-engine, dedicated Firecracker requirement. A reduced service list needs to be a deliberate workload/cost choice and must not be represented as a different isolation model or an undocumented feature restriction.

## Authentication and transport [#authentication-and-transport]

Configure capability verification before serving customer data. The relevant settings include `AKASHA_REQUIRE_CAPABILITY`, the capability public key or key path, issuer, and audience. Restricted administration has a separate token and source-IP policy. Read the [authentication contract](/docs/api/instance/authentication) before exposing the daemon.

`AKASHA_REQUIRE_TLS` is a request policy; it does not by itself install a certificate or terminate TLS. A reverse proxy and forwarded headers must match the deployment design.

## Self-hosting checklist [#self-hosting-checklist]

Build or obtain an approved versioned Akasha artifact, use a persistent data location, configure authority and private listeners, and start with a harmless authenticated read. Then verify a write/read/reconnect workflow and a recovery exercise before depending on the instance. This documentation audit did not certify a new self-hosted deployment.

[Service administration](/docs/api/instance/administration) · [Protocol reference](/docs/api/instance/protocols)