Space Engine – the server platform of the Space Intelligence ecosystem
Space Engine Servers
The Space platform in three deployment models: from a shared cloud to an installation in your own data centre. You decide where the servers run, who operates them and where the data stays.
Space Engine servers are the back end of the whole Space system: they receive events from locks, terminals, intercoms, lifts and sensors, execute commands and expose them to your applications through an API. The same Space Engine platform runs in each of the three models, so choosing a model is a decision about infrastructure and responsibility, not about features.
Three deployment models
Space Engine Cloud
SaaS · multi-tenant · bare metal
Shared cloud (SaaS) on Space bare-metal servers. Logical tenant isolation, no infrastructure of your own, the fastest start.
Space Engine Private Cloud
IaaS · single-tenant · Proxmox VE
A private cloud on Space infrastructure: dedicated Proxmox VE virtual machines just for you, managed by Space. Dedicated-server isolation with cloud convenience.
Space Engine Self-Hosted
The same software at your site or in your data centre, in two delivery variants.
Space Engine Edge
Self-Hosted · appliance · plug-and-play
An appliance: a ready server module whose hardware we select and preconfigure. You plug it in on site and it runs; data stays on site and, where required, the system runs without internet access.
Space Engine On-Premise
Self-Hosted · BYOI · Kubernetes · Docker · bare metal
A customer-managed (BYOI) deployment on infrastructure you own or provide: Kubernetes, Docker or bare metal, Linux recommended. The infrastructure must meet the minimum requirements; we tailor the deployment to your environment.
Model comparison
| Parameter | Space Engine Cloud | Space Engine Private Cloud | Space Engine Self-Hosted | |
|---|---|---|---|---|
| Space Engine Edge | Space Engine On-Premise | |||
| Hosting location | bare-metal servers in Space locations | Space infrastructure (Proxmox VE) | at the customer’s site | customer’s infrastructure and hardware |
| Isolation | logical (multi-tenant) | dedicated virtual machines (single-tenant) | physical, isolated network, air-gap option | full, in the customer’s network, air-gap option |
| Operated by | Space | Space | the customer, with Space support | the customer’s IT team, with Space deployment support |
| Environment | managed by Space | Proxmox VE virtual machines | Intel server, base configuration i5-6400 / 16 GB | Kubernetes, Docker or bare metal; Linux recommended |
| Scaling | handled by Space | more virtual machine resources | upgraded configuration or Kubernetes cluster | from one server to a cluster |
| Typical customer | hotels, offices, sites without their own IT | organisations that need isolation without their own servers | sites that need isolated infrastructure: public administration, hospitals, critical infrastructure | large organisations with their own IT and data centre |
For CTOs, IT architects, CISOs and integrators
One platform, three models, full control
A rare combination: the same platform and the same API, from a shared cloud to an air-gapped installation in your own data centre. That is why Space Engine fits hotels, offices and commercial real estate, residential and PRS, healthcare, the public sector, critical infrastructure and industry, while control of the infrastructure and security procedures can stay on your side.
Data sovereignty and residency
You choose where the servers run and where the data is stored: in the Space cloud, in a private cloud or at your own site. This makes it easier to design an architecture that meets GDPR and NIS2 requirements.
Your security governance
In the on-premise models the infrastructure follows your procedures: network segmentation, an air-gap option, your own identity and key management where applicable, your own backup and disaster-recovery policy, change management and update windows of your choice.
Every component authenticated
Every device connects to the MQTT broker with its own ID and key, and every application uses the API with its own keys and JWT tokens. This is a sound basis for a zero-trust approach. Event history and command status provide an audit trail.
No vendor lock-in
The same API across all models and migration between them without replacing devices: the server address in the hubs changes, not the hardware in the doors. You are never forced into a public cloud.
One stack for access and building
Access control, locks, intercoms, lifts, building automation and energy metering in one platform, and in the Space ecosystem also EV charging, energy storage and payment terminals. Vendor-neutral integration.
Lightweight, scalable technology
Event-driven microservices, MQTT with about 30 MB of traffic per hub per month, REST API and WebSocket. Deployment in containers (Docker, Kubernetes), on bare metal or in a Proxmox VE private cloud, from one server to a cluster.
Goes far beyond typical smart platforms and classic BMS
| Typical cloud smart platform | Classic BMS | SPACE Engine | |
|---|---|---|---|
| Deployment options | usually only the vendor’s public cloud | usually on site, in the vendor’s architecture | three models: Cloud (SaaS), Private Cloud and Self-Hosted (Edge or On-Premise) |
| Data location | set by the vendor | on site | your choice: Space cloud, private cloud or your site |
| Customer control over security | limited to account settings | depends on the integrator and vendor | full in the on-premise models: network, backups, updates, audit |
| API openness | often a limited API or partner-only integrations | often closed protocols and licensed interfaces | documented REST API, WebSocket and webhooks, the same in every model |
| Integration scope | mainly smart-home devices | mainly building services (HVAC, lighting) | access, locks, intercoms, lifts, automation and energy in one stack |
| Scaling | within the vendor’s plans | hardware and licence expansion | from one server to a Kubernetes cluster; change of model without replacing devices |
A qualitative comparison with typical solutions in each category; individual products may differ.
Platform architecture
The same stack runs in every model: on a single server, in virtual machines or in a Kubernetes cluster.
1. Devices
Locks, wall and face terminals, intercoms, lift controllers, sensors, switches and meters. Z-Wave devices connect through Space Gate hubs (S2 security, AES-128); NB-IoT and Wi-Fi locks and TCP devices connect through dedicated adapter services.
2. MQTT broker
Hubs and devices exchange lightweight MQTT messages with the server on separate channels for reports, commands and responses. One hub accounts for about 30 MB per month, mostly heartbeat.
3. Space Engine microservices
The core service registers and authenticates devices and applications, translates device protocols and maintains device shadows (cached state), the event stream and the operation log. Alongside it run protocol adapters and an integration and notification service (webhooks, e-mail, SMS, push, timed and conditional scenes).
4. Data layer
Cache and event streams, a command queue for sleeping devices, a NoSQL database for devices and users, and a time-series database with a data pipeline.
5. API and applications
REST API (HTTP/JSON) for commands and queries, WebSocket for live events and HTTP webhooks for external systems. The API documentation describes 273 methods and 120 event types. It is used by the Space app, the web console, hotel systems (PMS), BMS and partner applications.
Security
Devices
Each device authenticates with its own key, and message payloads are encrypted with the device key, which is never sent over the network. The Z-Wave radio is protected by S2 with AES-128.
Applications and API
API access requires a JWT token signed with the application key; each application has its own keys. The platform supports encrypted HTTPS and WSS communication.
Network and data
In the on-premise models the platform runs in your network, including without internet access; you can block outbound traffic at the firewall. Keys, permissions and event history stay in your infrastructure.
Audit and updates
The history of openings, failed attempts and the status of every command form an audit trail. Device firmware is updated over the air (OTA); in the on-premise models you set the update schedule.
Frequently asked questions
Space Engine Cloud when a quick start without your own infrastructure matters. Space Engine Private Cloud when you need isolation but do not want to run servers. Space Engine Self-Hosted when the system has to run at your premises: Edge is a ready appliance that we select and configure, and On-Premise is a deployment on infrastructure you own or provide. We will help you match the model to the project.
Yes. All models use the same platform, the same API and the same devices. During migration the server address in the hubs changes, not the hardware on site.
In the on-premise models (Space Engine Edge, Space Engine On-Premise), yes: the whole platform runs in the site’s local network. In Space Engine Cloud and Space Engine Private Cloud the hubs connect to the server over the internet.
Very little. MQTT communication is very light: one hub sends about 30 MB of data per month, mostly device heartbeat messages.
Through the REST API (HTTP/JSON), WebSocket and HTTP webhooks, the same in every model. We share the API documentation (in English) with integration partners on request.
Let’s match the model to your project
Tell us about your site and security requirements, and we will propose a deployment model, architecture and server configuration.
Call: +48 533 909 533