System requirements

What this chapter covers#

This chapter lists what release 1.0.0-rc.1 needs: the components and the versions its deployment files use, where it can be deployed, the services you provide, the ports and outbound connections, the clients, and the sizing defaults in the deployment files. Where the release states no minimum version or size, this chapter says it is not specified.

Runtime components#

Release images are built for linux/amd64 and linux/arm64; see Prepare the environment for signing, SBOMs and image mirroring.

Deployment targets#

Build toolchains#

These are needed only where you build images or the mobile apps, not on the hosts that run AckNexa.

Services you provide#

Every deployment needs these:

Only for the features you enable:

Ports#

The ports AckNexa components listen on inside their containers, as set by the supplied deployment files.

Outbound connections#

The core needs none of these: each is needed only when you enable the matching feature. Private destinations configured by an organization also need NOTIFICATION_PRIVATE_CIDRS; see Notification egress.

Clients#

See Web and mobile access for how the apps are distributed and how pages reach a phone.

Sizing#

This release has no certified sizing guide. The figures below are the defaults in the supplied deployment files, not a capacity statement. Validate CPU, memory, storage and connection limits against your own load, as described in Capacity and deployment evidence.

• Together, the default API, worker and Web pods request 3.6 CPU and 3.75 GiB of memory, with limits of 15 CPU and 15 GiB. PostgreSQL, NATS, ingress and monitoring come on top and are not sized by the chart.
• Each API pod opens up to 20 database connections and each worker pod up to 60 (config.apiDatabaseMaxConnections and config.workerDatabaseMaxConnections): up to 240 at the default replica counts, plus the migration Job. Allow for this in PostgreSQL's connection limit or a connection pooler; a pooler must pass statement_timeout through.
• With the chart defaults, each worker pod runs 24 escalation workers, 4 notification workers per channel and 4 raw-event workers.
• The on-prem Compose file sets no CPU or memory limits. The API and the worker each use the built-in pool of 20 database connections, NATS keeps one stream replica, and the optional Prometheus keeps 30 days of metrics.
• Disk sizes for PostgreSQL, NATS and backups are not specified. They grow with your event, incident and audit volume.

Storage and backups#

• PostgreSQL is the system of record: configuration, raw events, incidents, escalation jobs, notification attempts, the outbox and audit.
• Workers prune operational data hourly. By default, outbox rows go after 7 days, payloads of processed raw events after 30 days, and finished delivery rows after 30 days. Raw-event rows, incidents, timelines, notifications and audit events are kept until you archive or purge them; see Retention.
• NATS needs persistent file storage, but its stream is not authoritative: when the stream is empty, the workers recover every unprocessed raw event from PostgreSQL.
• Compose also keeps volumes for Redis, which is not authoritative, and, when their profile or overlay is enabled, for Prometheus, Grafana and voicemail recordings. Voicemail recordings are kept for 30 days by default.
• Keep ACKNEXA_CONFIG_KEY in an independently protected copy. Without it, saved provider credentials cannot be decrypted.

Small installs back up with scripts/onprem_backup.sh, which by default takes a consistent database snapshot while paging continues, and restore into a new, isolated project. Production uses your PostgreSQL tooling with continuous WAL archiving and point-in-time recovery to encrypted, customer-controlled storage; cloud object storage is not required. See Backups and disaster recovery.