Install Auto Learning Agents on a Linux Server
The Docker install is the fastest way to try the platform. A bare-metal install is the right choice when you want the platform integrated with an existing server, direct access to the files and processes, or full control over each dependency. Both paths end in the same place: one supervised application running every agent, with the web UI served by Apache.
Install the Dependencies
Three runtimes do the work. Elixir 1.14 or newer with OTP runs the platform itself. PHP CLI powers most of the tool layer and the web UI, and needs the sqlite3, imap, curl, and mbstring extensions. Python 3 runs the embedding and analysis services, and needs sentence-transformers, numpy, and sqlite-vec:
pip3 install sentence-transformers numpy sqlite-vec
For voice features, add faster-whisper for transcription and piper-tts for speech synthesis. Finally, install the claude CLI so the agents can use your model subscription, the same CLI the Docker image bundles.
Clone and Build the Release
Clone the repository, fetch the dependencies, and compile the production release:
git clone https://github.com/AIAppsAPI/auto-learning-agents cd auto-learning-agents MIX_ENV=prod mix deps.get MIX_ENV=prod mix release
The release is named cns_app and lands in rel/cns_app inside the install directory. It is fully self-contained, the Erlang VM ships inside it, so the build machine and the run machine only need to match in OS and architecture.
Configure Apache
The web UI is plain PHP served from the threads directory of the install. Point a virtual host at it:
<VirtualHost *:80>
DocumentRoot /opt/auto-learning-agents/threads
DirectoryIndex index.php
<Directory /opt/auto-learning-agents/threads>
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
Substitute your install path. The same vhost shape the Docker image generates works verbatim on a bare server, and docker/start.sh in the repository is the reference if you want to compare. Enable the site, make sure mod_php or PHP-FPM is active, and reload Apache.
Set Directory Permissions
The platform and the web UI both write to the runtime directories, so they must be writable by the service user and the web server user. That covers the threads subdirectories (prompts, output, flags, incoming, channels, audio, uploads, goals), plus work, autologs, loghistory, config, data, and memory. The simplest arrangement is a shared group: put your service user and www-data in one group, group-own those directories, and grant group write. Check settings.txt and set homepath to the absolute path of the install with a trailing slash, it is how every tool finds the installation.
Install the systemd Service
A unit template ships with the repository as cns-customerservice.service. Copy it in, point it at your install if your path differs, and enable it:
sudo cp cns-customerservice.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable --now cns-customerservice
The service starts the release, and the release supervises everything else: every agent, the pipelines, and the always-on Python services for memory and analysis on ports 9500 and 9510. There is nothing else to keep alive, the supervision tree restarts any component that stops, and systemd restarts the whole application if the host reboots.
Log In and Open the UI
Authenticate the claude CLI once as the service user:
claude login
Then browse to your server and sign in with the email and password from the users list in settings.txt, user accounts are managed from the UI afterward. Your first stop should be a conversation with the master agent, which can verify the install and walk you through configuring each area.
Verifying the Install
Three quick checks confirm a healthy system. The service is running: systemctl status cns-customerservice shows the release active. The services are listening: the memory bank answers on port 9500 and the analysis service on 9510, both supervised by the application itself with automatic backoff restarts. The UI responds: the dashboard loads, and the sidebar shows the system state. From there, configuration covers every setting, and AI models covers connecting the models your agents will think with.
Updating
Updates follow the same shape as the install: pull the source, rebuild the release, restart the service.
git pull MIX_ENV=prod mix deps.get MIX_ENV=prod mix release sudo systemctl restart cns-customerservice
Your data lives in the runtime directories, the SQLite database in data, the memory files, the conversation history, and the work queues, all of which stay in place across updates. settings.txt is re-read constantly while the system runs, so configuration changes apply live without touching the service at all.
Build the release with mix release, serve the threads directory with Apache, and let systemd plus the OTP supervision tree keep everything alive. One service runs the entire platform, and updates are a pull, a rebuild, and a restart.