Self-Hosted IoT Platform Operations Guide

The short answer: self-hosting is not about “putting the platform in your own server room.” It means that from the day you go live, availability, data security, and upgrade responsibility are entirely yours. If your team accepts that responsibility and puts backup, monitoring, and drills in place, self-hosting delivers full data sovereignty and customization freedom. If not, even the lowest license fee turns into incident cost later.

This article covers only implementation and operations decisions: deployment boundaries, deployment shape, security, backup, upgrades, operating cost, and acceptance. Choosing an edition and license is a separate question; see the Commercial vs Cluster selection guide, which this article does not repeat.

1. Draw the Deployment Boundary First

“Self-hosted deployment” is often treated as a single term in procurement talks, but it covers three very different shapes:

Shape	Who owns the infrastructure	Operations responsibility	Typical scenario
On-premises server room	Self-purchased servers and network	Hardware, OS, and platform all yours	Data must stay on the intranet; strong compliance constraints
Private or dedicated cloud	Cloud provider supplies the resource pool	Platform and OS yours; hardware on the provider	Unified group-level resource pools
Self-built on public-cloud VPC	Rented cloud hosts and networking	Platform and OS yours; underlying hardware on the provider	Elasticity needed without managed IoT services

Before choosing, write down answers to four boundary questions: Is data allowed to leave your domain? Must the system keep running when the external network is down? What audit requirements do security-classification or industry regulations impose? What has the customer contract committed about deployment location? These answers drive every later architecture decision.

The reverse boundary matters just as much: self-hosting does not mean building everything yourself. OS patches, databases, message middleware, and reverse proxies should all be mature components. FastBee's deployment documentation is organized around standard components such as JDK, MySQL, Redis, EMQX, and Nginx (see IoT System Deployment). Reserve your team's effort for business logic rather than rebuilding infrastructure.

2. Choose the Deployment Shape: Docker Validation, Single-Node Production, Cluster Expansion

Decide in three steps — validate, produce, expand — instead of jumping straight to a cluster.

1. Validation phase: the goal is a working business loop, not performance. For the Open Source edition, use Docker One-click Deploy or install components manually per System Deployment; for the Commercial edition, use Quick Deployment.
2. Production phase (single node): for small and midsize projects, deploy the backend, frontend, and Nginx per IoT System Deployment, with component guides for MySQL, Redis, EMQX, Nginx, and the time-series database as needed. Single-node production is only acceptable after benchmarking and failure drills (see sections 4 and 7).
3. Expansion phase (cluster): when single-node capacity or availability no longer meets objectives, evaluate the cluster path: FMQ Cluster Deployment, Kafka Installation, and Cluster Load Balancing. A cluster brings operational complexity, not free capacity; without the matching skills, tuning a single node is the better choice.

Whatever the shape, complete a full installation in a test environment before touching production. FastBee provides Run Locally & Visualization for validating the cluster chain on a local machine; the habit of reproducing locally first prevents many go-live incidents.

3. Security Baseline: Treat “Intranet” as an Assumption to Prove

The most common security illusion in self-hosted environments is “we are on the intranet, so we are fine.” Intranets still have weak passwords, privilege misuse, and compromised office terminals. Before go-live, at minimum:

• Entry-point reduction: expose only necessary ports; never expose the admin console, Broker management ports, or databases to the public internet. Use a VPN or bastion host for remote operations.
• Transport encryption: enable MQTT over TLS and HTTPS certificates, record expiry dates, and manage credentials for inter-component authentication separately.
• Credential management: change every default account and password; store EMQX/FMQ, MySQL, Redis, and Nginx credentials separately and include them in offboarding procedures.
• Vulnerability response: subscribe to security advisories for every component and write patch windows into the operations plan; FastBee's own fix cadence is documented in System Vulnerability Fixes.

For a layered approach, see Six Layers of IoT Platform Security. Security items belong in the acceptance checklist (section 7); a one-time check is not completion — schedule periodic reviews.

4. Backup Strategy: Decide What to Restore Before Deciding How to Back Up

Derive the backup plan from recovery objectives. First confirm two numbers with the business: RPO (how much data loss is tolerable) and RTO (how long an outage is tolerable). Then inventory the data assets in a FastBee deployment:

Data asset	Contents	Backup notes
MySQL	Business data: device records, users, rules, alerts	Scheduled full backups plus incrementals as needed, stored off-host
Time-series database	Historical device telemetry (when TDengine is enabled)	Large volume; evaluate snapshots or export policies against the retention period
Redis	Cache and transient state	Usually optional, but understand the rebuild impact of losing cache
Broker configuration	EMQX/FMQ authentication, ACLs, and rule configuration	Keep configuration files under version control
Uploaded files and site configuration	Platform uploads, Nginx configuration, certificates	Back up on the same cadence as the database; document restore steps

Three hard requirements:

1. Backups must live off-host or off-site: a backup on the same machine as the production database disappears with the same disk failure.
2. Regular restore drills: a backup that has never been restored successfully is not a backup; time the drill and compare it against the RTO.
3. A full backup before every upgrade: this is the precondition for rollback (see section 5).

5. Upgrades and Rollback: Treat Every Upgrade as a Small Release

A self-hosted platform has no “auto-update”; every upgrade is a release you execute yourself. The Commercial edition Upgrade Guide covers pre-upgrade preparation, upgrade order, SQL scripts, Docker-based upgrades, cache and time-series handling, post-upgrade acceptance, and rollback strategy — use it directly as the skeleton of your upgrade SOP. Key points:

1. Rehearse the full upgrade in a test environment using a copy of production data.
2. Upgrade components in the official order; execute SQL scripts one by one and keep execution records.
3. Accept after upgrading with a checklist: login, devices online, telemetry persisted, rules firing, alerts, visualization.
4. Write the rollback plan in advance: rollback = restore the backup + switch back to the previous version, which depends on section 4 backups actually working.

Skipping the test environment and upgrading production directly is the most common self-inflicted injury in self-hosted projects.

6. Operating Cost: The Staffing Bill Is Harder to Estimate Than the Server Bill

The real cost of self-hosting is mostly people. For a single-node production system, ongoing work includes:

• Daily inspection: service status, disk, database, message backlog. FastBee's Operations and Monitoring provides a daily inspection checklist, common commands, and in-platform operations entries you can reuse directly.
• Capacity watch: CPU, memory, and disk trends; compare connections and throughput against the benchmark baseline (see the Commercial stress test report for methods and metrics).
• Security maintenance: patches, certificate renewal, account audits.
• Backup and restore drills: execute and record per section 4.
• Upgrade execution and incident response: upgrades happen several times a year; incident response needs an explicit on-call or response agreement.

Budget guidance: assign at least one primary operator who can handle Linux, databases, and Java applications together, plus a designated backup owner, to avoid a “only one person understands it” single point of failure. In three-year total-cost comparisons, count this staffing alongside servers, bandwidth, and storage; the selection guide's total cost section explains the method.

7. Go-Live Acceptance Checklist

Acceptance item	Example pass criteria	Evidence
Functional loop	Device access, telemetry, rules, alerts, and visualization verified end-to-end with real devices	Test records
Capacity	Connections, throughput, and latency meet targets under the peak model with resource headroom	Raw benchmark data
Backup and restore	Drill restores to a standby environment successfully within the RTO	Drill records with timing
High availability (cluster)	Business recovers within the target time after a node failure	Fault-injection records
Security	Port scan, weak-password check, TLS, and credential review all pass	Inspection report
Upgrade and rollback	One upgrade-plus-rollback rehearsal completed in the test environment	SOP and execution records
Operations handover	Inspection, alerting, backup, and upgrade duties are owned and have been practiced	Handover documents and practice records

Fix acceptance criteria before go-live; do not loosen them after seeing results.

8. Recommended Implementation Sequence

1. Confirm deployment boundaries and compliance requirements (section 1).
2. Build the validation environment with Docker or a single node and complete the business loop.
3. Benchmark with real devices and the peak model to decide single node versus cluster.
4. Implement the security baseline and backup strategy, then complete one restore drill.
5. Complete one upgrade and rollback rehearsal in the test environment.
6. Accept against the section 7 checklist, finish the operations handover, and go live.

9. FAQ

9.1. What is the minimum staffing for self-hosted operations?

A single-node production system needs at least one primary operator covering Linux, databases, and the application, plus a designated backup owner. A cluster additionally requires Kafka, load-balancing, and Broker-cluster experience, which raises the staffing bar significantly.

9.2. Can the Open Source edition go straight to production?

Technically yes, but the official matrix licenses the Open Source edition under AGPL 3.0 for non-commercial use. Commercial projects should resolve licensing compliance before discussing deployment shape; see the license page and the edition selection guide.

9.3. What if we have no dedicated operations team?

Prefer a single-node shape with Docker to simplify deployment, script inspections and backups as scheduled jobs, and buy deployment support and operations services where needed; do not adopt a cluster without cluster experience on the team.

9.4. Do we still receive official updates after self-hosting?

The commercial license includes first-year source updates, with later updates through subscription. Each update still requires you to execute the section 5 upgrade and acceptance process yourself — there is no automatic upgrade in a self-hosted environment.