Home / Documentation / On-premises deployment

On-premises deployment

On-premises deployment delivers the whole platform to a customer’s own servers or private cloud, with data never leaving the intranet. Container orchestration is provided, so all services can be started with one command once the environment is ready.

4 sections · Updated with each platform release

What to prepare before deployment

  • One (or a group of) Linux servers, 4 cores and 8 GB to start; scale with device count and data retention when volumes grow.
  • MySQL: business data (products, devices, users, permissions and so on).
  • Redis: cache and sessions.
  • InfluxDB: device time-series data; space usage depends mainly on device count × reporting frequency × retention period.
  • Nginx: static frontend and reverse proxy for the API.
  • Docker and Docker Compose: to orchestrate the components above.

NoteTime-series capacity planning is the most easily underestimated item: estimate device count × rows reported per day × retention days first, then decide disk size and retention policy.

Deployment steps

Jiwu AIoT Platform · [object Object] Interface mock
1ProductsCreate the product and thing model → 2DevicesRegister devices under the product → 3Protocol onboardingMQTT reporting / Modbus polling → 4Data ScreensBind data and publish

Completing these four steps finishes onboarding: from one device to a dashboard you can show.

[object Object]
  1. Prepare the servers and dependency components, and confirm the required ports are free.
  2. Pull the backend and frontend code and adjust configuration such as database connections and Redis / InfluxDB addresses for the environment.
  3. Start the services with the orchestration files; the first start creates the required schema automatically.
  4. Run the database initialization script and the incremental upgrade scripts (they are idempotent and safe to re-run).
  5. Deploy the frontend static assets and configure the Nginx reverse proxy to the backend API.
  6. Configure the HTTPS certificate; do not expose the platform over HTTP in production.
  7. Sign in with the administrator account, confirm menus and permissions, then onboard the first device to verify the data path.

Upgrades

  • Back up the databases before upgrading (both the business database and the time-series database).
  • Pull the new version and rebuild, then run the incremental SQL scripts as described in the upgrade notes.
  • Upgrade scripts are designed to be idempotent, so re-running them has no side effects.
  • After upgrading, verify these four things first: sign-in, menu permissions, device data and data screen queries.

Go-live checklist

  • The administrator password has been changed and default accounts have been handled.
  • HTTPS is enabled and the certificate expiry date is recorded.
  • Scheduled database backups are configured, and a restore drill has been performed once.
  • The time-series retention policy is confirmed and disk alarms are configured.
  • The domains for the platform entry and the open API are separated as planned.
  • At least one real device runs the complete path of report → store → display on a data screen.