Your Gateway. On your infrastructure.

One package for a traceable release.

The standalone Gateway comprises Broker, integrated OCPP Server/CoreCPMS, admin interface, workflow/export worker and PostgreSQL. Redis is optional and disabled by default.

Prepare before starting the first container.

Verified with Ubuntu 24.04.5 LTS on Linux amd64, Docker Engine 28.0.4 and Compose 2.38.2. These are the versions actually tested, not blanket approval of all later versions. The supplied acceptance receipts include reference-host data; sizing for your operation is agreed separately.

Host and permissions

Your own Linux host or VM with amd64 architecture. Your IT team preinstalls Docker Engine, Compose v2, Python 3.12 and OpenSSL. The package launcher runs with local root privileges against the local Docker daemon.

Storage and backups

Persistent storage for PostgreSQL and configuration, plus space for images, updates and backups. Plan a separate protected backup location and a recovery test.

Networking and TLS

Prepare a DNS name, trusted TLS certificates, firewall rules and time synchronisation. Charge points must reach the WSS entry point; the Gateway must reach its primary backend and approved data destinations.

Configuration and ownership

Agree station identities, OCPP versions, the primary backend, additional destinations and operational responsibilities. Exchange credentials through the agreed protected channel, not the public contact form.

From approval to the first connection test.

Run these commands following the instructions supplied with the package. Replace paths, domain and <VERIFIED_KEY_SHA256> with your confirmed values. The fingerprint is SHA-256 of the public key in DER-SPKI format, not of the PEM file.

1. 01

   Obtain and verify the package

   Obtain the approved archive from the customer area. Before extracting or executing it, compare its SHA-256 checksum with the value supplied separately. Stop if they differ. Then extract it into a dedicated working directory; run the following ./neleso commands there. Record the release identifier and verification result.

   sha256sum /secure/neleso-gateway-0.1.0-pilot.11-linux-amd64.tar.gz

2. 02

   Prepare the installation

   Choose an installation path that does not yet exist and your DNS name. Supply an existing TLS certificate chain and private key. Installation separates release files from persistent data under shared/; protect secrets, configuration and TLS keys in particular. Do not reuse demo credentials.

3. 03

   Verify the signature and host

   Check the signed manifest, file inventory, host prerequisites and TLS files. check starts no containers and does not establish external reachability. Keep the public release key outside the package and installation target.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' check \
     --domain gateway.example.com \
     --certificate /secure/fullchain.pem \
     --private-key /secure/privkey.pem

4. 04

   Install the services

   Install within the agreed maintenance window after package checks pass. Switch existing charging operations only when configuration, target systems and the recovery path have been agreed.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' install \
     --domain gateway.example.com \
     --certificate /secure/fullchain.pem \
     --private-key /secure/privkey.pem

5. 05

   Sign in with your own credentials

   The local administrator account is named admin. Its individually generated password is stored at <installation path>/shared/secrets/admin-password. The responsible administrator reads it locally in a protected session and saves it in the organisation’s password manager. Do not copy it into tickets, screenshots or shared terminal logs.

6. 06

   Validate operation and routing

   Check service status and open the local admin interface over HTTPS. For later status and backup commands, you can use the installed launcher at <installation path>/releases/<release identifier>/neleso. Start with an agreed test station: trace the primary backend connection, OCPP responses and permitted data exports.

   sudo ./neleso --install-dir /opt/neleso-gateway status

Configuration and subsequent changes

The supplied installation.example.json is a template without secrets. check and install accept --configuration /absolute/installation.json with separate certificate and key paths. This option cannot be combined with --domain, --http-port, --https-port or --with-redis. Without JSON, add --with-redis to check and install to enable Redis. The package guide explains private OCPP/HTTPS/MQTT destinations.

Before changing shared/config.json or TLS files, create a backup and preserve file permissions. restart verifies the installed release and configuration, applies the changes with a controlled restart and checks service readiness. Connections may be interrupted.

sudo ./neleso --install-dir /opt/neleso-gateway restart

Install offline – plan how destinations remain reachable.

The complete offline package includes the required images. Transfer the entire verified package through the approved channel and verify it again after transfer. Individual container images do not replace a complete installation package.

• Docker Engine, Compose, Python 3.12 and OpenSSL must already be installed on the target host. The Gateway package does not install the operating system or Docker offline.
• Local Gateway operation does not require a mandatory NeLeSo cloud or telemetry connection. External OCPP backends, MQTT/HTTPS destinations, and DNS, time and certificate services still need their intended network paths.
• Updates can also be transferred as a new complete package. Offline operation does not mean the Gateway takes over charging decisions from an unreachable primary backend.

Schedule updates and back up the data first.

Version changes are deliberate. There are no unattended updates using a moving “latest” image. Only starting revisions explicitly approved in the manifest are accepted. An update may interrupt connections; agree a maintenance window.

1. 01

   Read approval and update requirements

   Check release notes, supported starting versions, configuration changes and database migrations. Retain the previous package and its instructions.

2. 02

   Create and verify a backup

   The backup briefly stops services to capture a consistent state. It contains the database, configuration and secrets and is not automatically encrypted. Choose a new backup destination that does not yet exist under a protected directory, then keep an encrypted off-host copy under your security policy and test recovery.

   sudo ./neleso --install-dir /opt/neleso-gateway backup \
     --output /secure/backups/before-maintenance

3. 03

   Verify the new package and update

   Obtain the complete target package, compare the independently supplied archive checksum and run check from the new package against the existing installation path. Start the update from the new package against the existing installation path, specifying a new backup destination. Do not mix files from different releases; check migrations and the final state.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' update \
     --backup-output /secure/backups/before-update

4. 04

   Validate the update

   Check status, local sign-in and connections. Validate the test station and primary backend, plus the additional backends, exports and workflows actually in use. Close the maintenance window only after these checks.

   sudo ./neleso --install-dir /opt/neleso-gateway status

Recovery takes more than the previous image.

Restore requires a new installation path that does not yet exist and the same signed release as the backup. After a database migration, switching to old containers alone is not a valid substitute. PostgreSQL major versions and the Debian/Alpine database base are not switched automatically. Retain the original package and its trust material.

• Record the failed update and its state. Do not layer further versions on top of an unclear migration state.
• Preserve and stop the previous system before the recovered system takes over its address or ports. Do not start a second active installation for the same stations. Use a target directory that does not yet exist; an existing installation is not overwritten.
• The recovered system contains the state captured in the backup. Later changes are not included. Test the backup beforehand in a separate environment without production station connections.
• After recovery, repeat the same status, connection and functional checks as after installation.
• For a renewed TLS certificate, add restore --certificate /path/fullchain.pem --private-key /path/privkey.pem alongside --backup. Both options are required together; the certificate must match the original domain.

sudo ./neleso --install-dir /opt/neleso-gateway-restored \
  --trusted-key /secure/release-public.pem \
  --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' restore \
  --backup /secure/backups/before-update

Release history and known limitations.

The complete release notes, SECURITY-REVIEW.md, original scans and installation/recovery receipts accompany the delivery in the protected customer area.