Astervis

The problem

What it solves

Astervis sells software that runs on the customer's own server, which creates two problems this codebase exists to solve. The buyer has to discover the product, subscribe, receive a license key, run a one-line installer, and get a real HTTPS subdomain provisioned automatically. The vendor has to prove a given install is licensed, bind it to a hardware fingerprint, meter and bill AI usage, ship signed releases, and revoke or transfer a seat — without ever touching the customer's machine. On top of that it hosts the AI layer a self-hosted install cannot run locally.

Day one

What the boilerplate supplied

Before a line of Astervis was written, these 9 packages were already working — auth with RBAC, a typed database layer, Redis caching, transactional email, shared types, the component library, and the setup CLI.

That was the baseline Astervis forked from. ShipKit ships 18 packages and 7 apps today, so some of what follows is now included out of the box.

On top

What this project added

■ analytics, docs are in ShipKit today — Astervis predates that and had to write them.

• ▸apps/ai-gateway + apps/ai-worker + packages/ai-core — the hosted AI layer the self-hosted product cannot run itself: transcription and analysis, QA scoring, and natural-language querying over the customer's own data.
• ▸License-key authority and server registry: keys are issued on purchase, bound to a hardware fingerprint, and validated by each running install.
• ▸One-line installer distribution with automatic subdomain provisioning, so a buyer gets a working HTTPS host without manual DNS work.
• ▸apps/b24-connector — a Bitrix24 Market connector, seven mounted modules bridging CRM entities and events.
• ▸packages/ai-evals — an evaluation harness for the AI features, separate from the runtime.

Wired in

Integrations and stack

Third-party services

Stack

Measured

By the numbers

Counted from the repository, not estimated.

Inside

A look at the product

More

Other apps on the same boilerplate