Post-Installation
Verify the install and take your first steps.
The installer finished and printed a green summary. Before you hand the dashboard to your team, take five minutes to confirm every service is healthy, that call data is flowing in, and that you know where everything lives on disk. This page walks through that checklist and your first few configuration steps.
Open the dashboard
The final screen of the installer shows everything you need to log in:
✓ Installation complete
Dashboard: https://192.168.1.100:8443
Username: admin
Password: aB3xYz9wQ1mKAstervis is exposed on a single HTTPS port — 8443 — at https://<server>:8443,
where <server> is your server's IP or the domain you chose during install. Every
other service binds to 127.0.0.1 and is never reachable from outside the host.
If you chose the self-signed certificate fallback, your browser will warn
that the connection isn't private. That's expected — click Advanced →
Proceed. To get a trusted certificate with no browser warning, re-run the
install and pick the free *.web.astervis.io subdomain or a Let's Encrypt
option. See SSL & domains.
Log in with the admin username and the generated password. Save that password in
your password manager now — the installer does not store it in plain text anywhere,
and resetting it later takes a few extra steps (covered below).
Verify services
From the server shell, ask the installer for a health report:
sudo astervis-installer statusIt runs docker compose ps against /opt/astervis and prints a per-service table
with a roll-up line at the bottom:
Astervis Status — /opt/astervis
────────────────────────────────────────────────────────────
SERVICE CONTAINER STATUS HEALTH
────────────────────────────────────────────────────────────
timescaledb astervis-timescaledb Up 6m healthy
redis astervis-redis Up 6m healthy
migrate astervis-migrate Exited (0) —
app astervis-app Up 6m healthy
nextjs astervis-nextjs Up 6m healthy
queue astervis-queue Up 6m —
litcdc astervis-litcdc Up 6m running
replication astervis-replication Up 6m —
nginx astervis-nginx Up 6m healthy
────────────────────────────────────────────────────────────
Services: 8/8 running · migrate: completed (one-shot)migrate showing Exited (0) is correct. It is a one-shot container that
runs the database migrations once and then exits cleanly. An exit code of 0
means migrations succeeded. You'll see eight long-running services plus this one
completed job.
If any service is restarting or unhealthy, jump to viewing logs to see why, and check the Troubleshooting guide — most first-run issues are host networking quirks that the installer's logs pinpoint immediately.
What each service does
Astervis runs as a small set of Docker containers, all orchestrated by Docker Compose and managed through the installer. Here's what each one is responsible for:
| Service | Container | Role |
|---|---|---|
| timescaledb | astervis-timescaledb | Analytics store — PostgreSQL 16 with TimescaleDB and pgvector. Holds replicated CDRs, AI transcripts, and vector embeddings. |
| redis | astervis-redis | Session cache and the BullMQ job queue backend. |
| migrate | astervis-migrate | One-shot job that applies database migrations on each upgrade, then exits. |
| app | astervis-app | Backend API (Elysia.js on Bun). Auth, REST endpoints, integrations, AI orchestration. |
| nextjs | astervis-nextjs | The dashboard web app you log in to. |
| queue | astervis-queue | Background worker — operator import, CRM sync, AI transcription submission, insights. |
| litcdc | astervis-litcdc | Change-data-capture service. Reads the Asterisk MySQL binlog and serves CDR changes over an HTTP long-poll feed. |
| replication | astervis-replication | Consumes the litcdc feed and writes call records into TimescaleDB in realtime. |
| nginx | astervis-nginx | Reverse proxy and TLS termination — the only externally exposed service, on port 8443. |
litcdc is Astervis's own lightweight CDC engine — a single Rust binary that
replaced the heavier Debezium + Redpanda pipeline used in older builds. It takes
a one-time consistent snapshot of your existing cdr table for historical
backfill, then streams new calls live. Read more in How sync
works.
View logs
When you need to see what a service is doing, use the installer's logs command.
Stream the combined log of every container:
sudo astervis-installer logs --followThe full installation log — invaluable when something failed during setup — is written under the install directory and its path is printed at install time. If you ever open a support ticket, this single file contains the per-container diagnostics the team needs.
First steps
With the dashboard open and services healthy, here's the recommended order to get a useful first view of your call center.
Confirm your operators imported
During installation, Astervis imports your agents directly from the Asterisk MySQL database. Open the Operators page and check the list looks right. If you added agents in your PBX after installing, re-run the import or add them manually — they'll then be matched to calls automatically.
Check that calls are syncing
Open the Calls page. On a fresh install, litcdc backfills your historical
cdr table first, so you should already see past calls. To confirm realtime
sync, place a test call through your PBX, wait a few seconds, and refresh — the
new record should appear on its own. If the page is empty, see
Troubleshooting → no data.
Configure an integration (optional)
Connect your CRM so deals and sales analytics line up with your calls. Astervis supports deep two-way Bitrix24 sync and a full OAuth amoCRM marketplace integration, plus omnichannel Open Lines for Telegram and WhatsApp. Set these up under Settings → Integrations.
Turn on AI analysis (if your plan includes it)
If your license has the AI tier, transcription, QA scoring, and sentiment analysis start running automatically on new recorded calls — nothing else to deploy. See AI Call Analytics for what you get from every call.
Integrations
Connect Bitrix24, amoCRM, Telegram and WhatsApp.
AI Call Analytics
Transcripts, QA scores and semantic search on every call.
Troubleshooting
Fix the common first-run networking and sync issues.
Directory structure
Everything Astervis writes lives under /opt/astervis. Knowing this layout makes
backups, log digging, and the occasional manual edit straightforward.
| Path | What it holds |
|---|---|
.env | All generated configuration — DB passwords, secrets, MySQL connection, ports. Mode 0600. Treat as secret. |
docker-compose.yml | The rendered service definitions the installer manages. |
nginx/ | The reverse-proxy config (nginx.conf) and your TLS certificate + key in nginx/ssl/. |
litcdc_data/ | The durable CDC buffer (redb). Survives restarts, so litcdc never has to re-snapshot. |
timescaledb_data/ | The PostgreSQL/TimescaleDB data directory — your call data, transcripts, and embeddings. |
redis_data/ | Redis persistence. |
uploads/ | User-uploaded files served by the backend. |
.backups/ | Config + certificate snapshots the installer tars up automatically before each upgrade. |
Don't hand-edit docker-compose.yml or .env unless a support engineer asks you
to. Most settings have a managed counterpart, and the installer can regenerate
these files. The two folders you most want in your own backup routine are
timescaledb_data/ (your data) and .env (the keys to read it).
Reset the admin password
Lost the generated admin password? You can set a new one directly in the database.
Connect to the TimescaleDB container with psql, then update the user's password
hash.
Astervis hashes passwords with bcrypt via Better Auth. Use the database account
from your .env — the value of POSTGRES_USER (default astervis) and
POSTGRES_DB. The example below assumes the defaults.
Open a psql shell in the database container
docker exec -it astervis-timescaledb psql -U astervis -d astervisUpdate the password hash
Replace NewStrongPass1 with your new password and admin@example.com with
the admin account's email:
UPDATE "user"
SET password = crypt('NewStrongPass1', gen_salt('bf'))
WHERE email = 'admin@example.com';Then type \q to exit. Log in to the dashboard with the new password right away.
Sessions are cached in Redis. If an old session lingers after a reset, restart
the stack to clear it cleanly with sudo astervis-installer restart.
Next: Troubleshooting — common first-run issues and the one-command fixes the installer applies for them.
Last updated on