You have hosting requirements
The application stack, configuration, and operational data must reside in company infrastructure.
Deployment in customer infrastructure
MassAccess on-premise with Docker Compose or Kubernetes
Deploy MassAccess in company infrastructure as a self-contained Docker Compose stack or as versioned Kubernetes Helm releases. Your team controls the infrastructure, upgrades, and backups; cloud connectivity remains required for licensing, message metering, billing, and image delivery.
- 01Hosting
- On a company server or cluster
- 02Operations
- Managed by your team
- 03Connectivity
- Outbound HTTPS required
When on-premise makes sense
Choose this model when infrastructure control matters more than fully managed operations.
You need change control
Your company chooses when to install updates and can roll back using a documented procedure.
You have an operations team
A DevOps team owns the server or Kubernetes cluster, network, TLS, monitoring, backups, and recovery.
Choose a delivery method
Docker Compose and Kubernetes are separate supported delivery paths. Select one before preparing infrastructure; do not mix their commands or lifecycle.
Docker Compose
A self-contained 14-service stack for one customer-managed Linux server.
- Docker Compose archive with install, healthcheck, upgrade, and rollback scripts
- Bundled PostgreSQL, Kafka, ClickHouse, and Redis with six isolated volumes
- Host-level reverse proxy, TLS, monitoring, backup, and restore are operated by your team
Kubernetes and Helm
Two versioned Helm releases for application workloads and optional bundled data.
- external-data, bundled-data, and mixed-data placement profiles
- Kubernetes 1.33–1.36, Helm 4.2, real CNI enforcement, and a reviewed CSI/StorageClass
- Cluster platform, Secrets, ingress or Gateway, TLS, monitoring, and backups remain operator-owned
How on-premise differs from SaaS
The sending workflow stays the same; the hosting location and operational ownership change.
| Characteristic | SaaS | On-premise |
|---|---|---|
| Application hosting | MassAccess infrastructure | Company infrastructure |
| Dashboard and API | Available at massaccess.net | Available through a local address or company reverse proxy |
| Updates | Performed by MassAccess | Run by the company through upgrade.sh or the Helm lifecycle |
| Monitoring and backups | MassAccess responsibility | Company responsibility |
| License, metering, and billing | Cloud-based | Remain cloud-based |
What stays local and what remains in the cloud
On-premise moves the application environment, but it does not turn MassAccess into an isolated standalone product.
Inside company infrastructure
- Application services, local dashboard, and API
- Company configuration, scenarios, bot settings, and operational data
- Logs, monitoring, and backups managed by the company
MassAccess cloud services
- License issuance and state control
- Signed usage counter and assigned message tariff
- Balance, billing, and access to the deployment package and updates
Important: this is not an offline or air-gapped solution
The server needs continuous documented outbound access for license heartbeat, signed usage metering, cloud billing, image delivery, and Telegram and MAX integrations. Messaging is suspended when the heartbeat is lost.
Environment requirements before installation
Requirements depend on the selected delivery method. The manual separates the Compose host baseline from Kubernetes cluster prerequisites and preflight checks.
- Delivery method
- Compose or Helm
- Choose one lifecycle and use its dedicated package and guide
- Container platform
- Docker or Kubernetes
- Compose needs Docker 24+ and Compose 2.24+; Helm needs Kubernetes 1.33–1.36 and Helm 4.2
- Compute capacity
- Preflight required
- Validate actual workload, platform overhead, quota, and node allocatable capacity
- Persistent storage
- Volumes or CSI
- Compose uses host volumes; bundled Kubernetes requires a reviewed RWO StorageClass
- Network
- Outbound HTTPS
- Plus working DNS and enforced CNI NetworkPolicy for Kubernetes
- External access
- TLS entry point
- Use a host reverse proxy or an existing Ingress/Gateway controller; charts install no controller or certificate automation
How deployment works
Both delivery methods provide a separate, sequential installation and verification flow. Choose the method before downloading configuration.
- 01
Create a license and choose a method
Register your company, create the on-premise key, then choose Docker Compose or Kubernetes in the configurator.
- 02
Prepare the target
Validate the Compose server or Kubernetes cluster, capacity, storage, network policy, and required outbound connections.
- 03
Verify the delivery
Check the immutable package or release candidate, non-secret configuration, and Secret references before installation.
- 04
Install in the documented order
Run install.sh for Compose, or install the data Helm release before the application release and run helm test.
- 05
Validate and hand over
Check readiness, dashboard sign-in, API, WebSocket, webhooks, authenticated data paths, monitoring, and a restore drill.
Who owns what
The responsibility boundary should be explicit before selecting a delivery model.
Your company team
- Server or Kubernetes cluster, network, DNS, CNI/CSI, entry point, and TLS
- Secure storage of configuration and secrets
- Monitoring, free capacity, and incident response
- Backups, recovery validation, and running updates
MassAccess
- Compose package or versioned Helm charts, application images, and lifecycle procedures
- Documented requirements, diagnostics, and rollback procedures
- Cloud license lifecycle and signed message metering
- Unified API contract and application stack updates
What happens after launch
On-premise is an ongoing operational responsibility, not a one-time installation.
Observability
Monitor service health, logs, external dependencies, and available infrastructure capacity.
Backups
Back up data and configuration using the documented procedure and regularly validate recovery.
Upgrade and rollback
Run upgrade.sh or the reviewed Helm upgrade in a chosen change window; prove a compatible restore before upgrading.
Pricing
On-premise pricing
There is no separate deployment package fee. Registration bonus messages are used first; later sends use the company tariff through cloud billing.
Pricing detailsOn company registration
500
Free messages to get started
No usage expiration
then
RUB 0.59
per message
No subscription fee
Questions before choosing on-premise
Answers for IT, security, finance, and product teams.
Can MassAccess run in a fully isolated segment?
No. An active license, metering, billing, image delivery, and integrations require documented outbound connectivity.
What data leaves the company environment?
Cloud services receive license state and signed usage-metering data. Message content and service data interact with the selected messenger for delivery. Review the complete network boundary in the manual before architecture approval.
Do we need a public IP, domain, and TLS?
Not for access limited to your internal network. If the dashboard or API is internet-accessible, use a domain, TLS, and reverse proxy; do not expose internal service ports directly.
Are updates installed automatically?
No. Your company selects a change window and runs upgrade.sh for Compose or the documented Helm upgrade for Kubernetes. Both procedures require checks and a compatible rollback or recovery decision.
Is Kubernetes a replacement for Docker Compose?
No. They are separate supported delivery methods. Compose remains a self-contained server stack; Kubernetes uses versioned application and data Helm releases with external, bundled, or mixed data placement.
Who is responsible for backup and recovery?
Your company team. The package documents the commands, while scheduling, backup storage, and regular recovery testing remain your responsibility.
Can one license run on multiple instances?
No. Running the same licensed package on multiple instances at the same time may suspend the license.
How are messages billed?
The package has no separate price. Bonus, balance, and tariff remain cloud-based, while on-premise submits a signed usage counter for billing.
Agree on the infrastructure boundary first
Choose Compose or Kubernetes, validate the matching infrastructure and responsibility boundary, assign monitoring and backup owners, then create a license and proceed to the dedicated guide.