Skip to content

Cookie preferences

We use cookies for our own analytics, to see how our campaigns perform and, if you allow it, to load content from other services such as the Google site search. We never sell your data. Necessary cookies keep the site working and cannot be switched off. See our Cookie Policy for details and our Privacy Policy for how we handle personal data.

Security, load balancing and remembering your cookie choice.

Show us which pages people read, how they find the site and where they get stuck, so we can improve it (Google Analytics, Microsoft Clarity).

Show us which of our ad campaigns bring visitors to the site and remember the campaign or partner link you arrived from (Google Ads, LinkedIn, Meta, partner program). We do not use these cookies to build advertising profiles.

Load the site search from Google when you use it. Google sets its own cookies and shows ads in the search results.

© 2026 The ThingsBoard Authors
22.6k Try for free

ThingsBoard Cloud

Choose your data region

Your data stays in the region you choose, for residency and compliance. No credit card required.

Rather run it yourself? Install on your own servers

Remote Agent: Manage Remote Docker Hosts from ThingsBoard

On this page

A ThingsBoard deployment is often more than the platform. A hotel chain runs ThingsBoard Edge in its hotels, a manufacturer runs IoT Gateway in its plants, and an MQTT broker or a local database runs on the same host, behind NAT at the customer’s site.

Each of those hosts runs software you have to install, upgrade and monitor. With a few sites, that’s routine. With hundreds, it means an SSH session to every host, configuration changed by hand, and the 2 a.m. “is it still running?” check.

Other Docker management tools can run the containers, but they don’t know about ThingsBoard Edge or IoT Gateway versions, database migrations or the entities those applications connect to.

Remote Agent brings those hosts into ThingsBoard. A small container on each host connects outbound to ThingsBoard, and you deploy, upgrade and monitor its Docker Compose applications from the same UI that manages your devices. It works the same for one host or hundreds: routine work doesn’t need SSH, and you upgrade a whole fleet with one bulk action. Remote Agent is available in ThingsBoard 4.4 and ThingsBoard Cloud.

Playing this video loads it from YouTube (Google), which sets cookies on its own domain. See our Cookie Policy.

Video: https://www.youtube.com/watch?v=14quDoeEybA

TL;DR

  • Remote Agent is a Docker Compose manager built into ThingsBoard. You run one small container per host and manage everything else from the ThingsBoard UI. How it works →
  • On a single host, you deploy any Compose project, watch CPU, memory, disk and live container logs, and update or upgrade with volume backups and automatic rollback. One host →
  • Built for ThingsBoard: it finds new ThingsBoard Edge and IoT Gateway versions for you, upgrades them with database migration and automatic rollback, and creates the Edge or Gateway entity with its credentials. Upgrades →
  • For a fleet, every host joins with the same provisioning command, installs its assigned applications on its own, and is upgraded with one bulk action. Fleets →
  • The agent connects outbound only, so hosts need no public IP, open ports or VPN. What to plan for →

How does Remote Agent connect to a remote host?

The agent runs as a Docker container on the remote host. It opens an outbound gRPC stream to ThingsBoard, on the same port ThingsBoard Edge already uses, and authenticates with a routing key and secret. ThingsBoard sends step-based commands over that stream. The agent executes them against the local Docker Engine and reports progress for every step.

Remote Agent architectureThingsBoard sends commands over a two-way gRPC stream to the Remote Agent, which drives the Docker Engine to manage the Docker Compose projects on the host: ThingsBoard Edge, IoT Gateway, and custom applications. State, metrics, and logs flow back to ThingsBoard.ThingsBoardgRPC (routing key + secret)Remote hostRemote AgentDocker Engine API/var/run/docker.sockDocker EngineDocker ComposeprojectsThingsBoardEdgeIoT GatewayCustomapplicationcommandsstate, metrics, logs

Four design decisions make it a good fit for production hosts:

  • Outbound connections only. The agent opens no listening ports, so the host needs no public IP, port forwarding or VPN.
  • Exactly-once execution. Every step is idempotent, and the agent records each finished step. The server watches every running operation and resends the current step when no progress arrives, so a dropped message only delays the work, and a step that already finished isn’t repeated. After a reconnect or an agent restart, execution continues from the first unfinished step.
  • Rollback to the last working version. Before an update or upgrade, the agent snapshots the application and backs up the volumes you select. If a step fails on the host, the agent restores those volumes and the previous containers. If the operation fails on the server side, ThingsBoard sends the rollback itself. Either way, the application ends on its previous working version.
  • Plain Docker underneath. The agent talks to the Docker Engine API directly, so the host needs only Docker, without the Compose CLI or Compose files. It uses the standard Docker Compose labels, so your applications remain ordinary Compose projects, and containers you started yourself can be brought under management by recreating them with the standard Compose labels.

How do you manage a single remote host?

Remote Agent on a single hostAn IoT Gateway already runs on the host. The agent is installed with one docker run command and keeps a two-way gRPC stream to ThingsBoard and a local link to the Docker Engine. It discovers the running Gateway. An Edge is added in the install wizard, which creates the Edge entity and its credentials. When Edge 4.4 is released, one click upgrades it: volumes are backed up, the database is migrated, and Edge 4.4 starts. 1 · A Gateway already runs on the host. Install the agent with one command2 · Two-way gRPC link to ThingsBoard, local link to the Docker Engine3 · The running Gateway is discovered, no redeploy needed4 · Add an Edge in the install wizard: entity and credentials included5 · A new Edge version is released: upgrade in one click6 · Upgrade with volume backup, database migration, auto-rollbackThingsBoardEdge management › AgentsNo agents yetAgent-3f9a2c1b · Applications+ Add applicationAgent-3f9a2c1bRemote Agent · tb-remote-agentOnlinetb-gatewayIoT Gateway 3.8 · already runningDiscoveredEdge-a1b2c3Edge 4.3 · entity & credentials createdEdge 4.4 · entity & credentials createdInstallingRunningUpgrade availableUpgradingUp to dateApplication typeEdgeGatewayGenericEdge 4.4 releasedTemplate synced from GitHub · Upgrade availableEvent progress · UpgradeEdge-a1b2c3Back up volumesStop Edge 4.3Migrate databaseStart Edge 4.4Remote host$ docker run -d --name tb-agent \ -e TB_AGENT_ROUTING_KEY=… tb-remote-agentRemote AgentDocker EngineDocker APIgRPC streamagent-initiatedno open portstb-gatewayCompose projecttb-gateway:3.8running, unmanageddiscoveredEdge-a1b2c3Compose projecttb-edge:4.3tb-edge:4.3tb-edge:4.4postgres:16migrating…edge-dataedge-data.bakdiscoveredinstall Edgeupgrade Edge

Start with one machine. In ThingsBoard, go to Edge management > Agents, click Add new agent, and copy the generated docker run command. The server address and credentials are already filled in. Run it on the host, and the agent shows up as Online. From that moment, you manage the host from the UI.

Connecting a host to ThingsBoard: Add agent on the Agents page, the generated docker run command to run on the host, and the agent appearing Online

Deploy any Docker Compose application

Click Add application and pick a type:

  • Edge: a ThingsBoard Edge instance, linked to its Edge entity and credentials automatically.
  • Gateway: a ThingsBoard IoT Gateway, linked to its gateway device the same way.
  • Generic: any Docker Compose project, such as an MQTT broker, a database, a dashboard or your own service.

Pick a predefined application profile for the version you want, adjust its Compose configuration if you need to, and click Install. You follow the install step by step as the agent pulls images and starts containers, and the application then appears in the list.

Installing an Edge application from the agent’s Applications page: Add application, choose the Edge type, pick a predefined Edge profile, compare its Docker Compose template with your edits, and follow the install progress

Compose projects that already run on the host don’t need to be redeployed. When the agent connects, it discovers them and reports them to ThingsBoard, and you manage them as they are.

A Mosquitto broker discovered on the host next to an installed ThingsBoard Edge application

Watch metrics and live logs

The agent continuously reports what runs on the host. On the agent’s Applications page, the chips at the top show host CPU, memory and disk. Hover one for details, or click the chart icon next to them to open the history of every application on the host, stacked.

Host-wide metrics on the agent’s Applications page: the CPU chip with its tooltip, the chart icon, and stacked CPU and memory history for every application on the host

Click an application to open its details. The same chart icon there breaks CPU and memory down per container, so you see which service is busy.

Application metrics: the application’s details page with its Docker Compose configuration, the chart icon, and stacked CPU and memory history per container

The Units tab lists the application’s containers, volumes and networks with their images and state. Click the log icon on a container to stream its logs live into the browser, with highlight filters, pause, copy and download.

Live container logs: the log icon on a container in the Units tab opens the log viewer, streaming the container’s logs with a highlight filter, pause, copy, and download

Update and upgrade with automatic rollback

Two actions change a running application:

  • Update applies a changed Compose configuration on the current version, such as new environment variables, a re-pulled image or rotated credentials.
  • Upgrade moves a ThingsBoard product, like ThingsBoard Edge or IoT Gateway, to a new version. This is the action that runs the database upgrade scripts.

ThingsBoard syncs the templates for its products from a public repository, so when a new version ships, the deployed application is marked Upgrade available. This works without updating the platform.

Both actions use the rollback described above: if any step fails, the application returns to its previous working version with the backed-up volumes, and canceling a running operation rolls it back the same way. Every step is visible in the event progress view as it runs.

Click Upgrade on the application, and ThingsBoard merges the new image version into your configuration. The left side shows what ThingsBoard suggests from the new template, and you merge anything else you need into the right side. Pick the volumes to back up, confirm, and the agent stops the old version, migrates the database and starts the new one.

Upgrading ThingsBoard Edge from 4.3.1.6 to 4.4.0: the Upgrade button, the new template merged into your Docker Compose configuration side by side, the volumes to back up, and the event progress with the database migration running

Upgrade PostgreSQL to a new major version

A PostgreSQL data directory isn’t compatible across major versions, so a new major version needs a dump and restore, not just a new image tag. Remote Agent does that step for you. In the merge above, your configuration keeps postgres:15 while the Edge 4.4 template ships postgres:16, and you can take the new major version in the same upgrade or in any later update. When an update or upgrade moves a service based on the official postgres image to a new major version, the agent detects it, backs up the volume, dumps the database with the old version and restores it with the new one. The migration resumes after a crash and rolls back with the rest of the operation if it fails.

Keep the agent up to date

The agent upgrades itself, too. When a new agent image is published, click Upgrade agent. The agent pulls the image, starts a replacement container with the same settings, hands the host over and removes the old one. Your applications keep running throughout, and if the handover doesn’t complete, the old agent keeps serving. See Agent self-upgrade.

How do you manage a fleet with one configuration?

Most fleets run the same stack on many hosts: an Edge per hotel, a gateway per plant, the same broker and service bundle at every customer site. Remote Agent keeps those hosts consistent with two kinds of profiles.

Remote Agent fleet managementThe same provisioning command runs on three remote hosts; each registers as an agent and installs ThingsBoard Edge from the shared application profile. When Edge 4.4 is released, the application profile is upgraded once and a single bulk upgrade runs on every host. Two hosts finish on Edge 4.4; one fails and rolls back with its data restored, without affecting the others. 1 · One provisioning command, the same on every host2 · Each host registers itself and installs Edge automatically3 · A new Edge version: upgrade the application profile once4 · One bulk upgrade for the whole fleet5 · Every host upgrades, and rolls back, on its ownThingsBoardEdge management › ProfilesAgent profile · Factory fleetAuto-provisioning · installs assigned apps$ docker run … TB_PROVISION_KEY=… agentApplication profile · Factory EdgeTemplate Edge 4.3Template Edge 4.4 · profile upgradedEdge 4.4 releasedEdge 4.4Agents onlineEdge applications01230123Bulk upgrade · Factory EdgeUpgrade allAgents reporting success–0 / 31 / 32 / 3Done012Error01Running03210Pending030Remote host · Plant A$ docker run … TB_PROVISION_KEY=… agentAgent-3f9a2c1bOnlineinstallupgradeEdge applicationtb-edge:4.3tb-edge:4.4InstallingRunningUpgrade availableUpgradingUp to dateRemote host · Plant B$ docker run … TB_PROVISION_KEY=… agentAgent-7c41d0e9OnlineinstallupgradeEdge applicationtb-edge:4.3tb-edge:4.3InstallingRunningUpgrade availableUpgradingRolled backRemote host · Plant C$ docker run … TB_PROVISION_KEY=… agentAgent-b28e5a74OnlineinstallupgradeEdge applicationtb-edge:4.3tb-edge:4.4InstallingRunningUpgrade availableUpgradingUp to date

Application profiles: define the stack once

An application profile is a reusable application configuration: the type, a template version, the Docker Compose configuration and custom arguments. You create it once, and every application deployed from it shares that definition. There are two ways to create one:

  • Predefined profiles: pick a card from Quick start, a ready-made ThingsBoard Edge or IoT Gateway profile for a specific version, created in one click.
  • Add application profile: build your own. Choose the type and template version, then edit the Docker Compose configuration next to the read-only template. Use it for customized Edge or Gateway setups, or for any other Compose application, like the Mosquitto broker below.

Creating application profiles: the Quick start panel with predefined profiles created in one click, and Add application profile opening a custom Docker Compose configuration for a Mosquitto broker next to the template

When you edit the profile, running applications stay as they are. Applications that no longer match are marked out of sync in the In Sync With App Profile column, and you choose when to apply the change. When a new Edge or Gateway version arrives, upgrading the profile shows a side-by-side merge of the new template into your configuration, so your customizations carry forward. It’s the same side-by-side view as in the upgrade above.

Agent profiles: provision a fleet with one command

An agent profile describes how new hosts join and what they run. Use the default profile, pick a preset (Edge, Gateway or Edge + Gateway), or configure your own, and ThingsBoard gives you a provisioning command.

That command is the same for every machine, so you can put it in your setup script, a cloud-init file or the checklist your field technicians follow. Each host that runs it registers itself as a new agent and, depending on the provisioning strategy, installs the assigned applications automatically. You don’t generate credentials or copy Compose files per site.

Agent profile provisioningOne agent profile produces one provisioning command. The same docker run command runs on every remote host; each host registers as a new agent, and the agent installs the Edge and Gateway applications the profile defines.Agent profileOne application per typeone provisioning commandprovision key + secret$ docker run ... thingsboard/tb-remote-agentrun on every hostrun on every hostRemote host 1Agent 1EdgeGatewayRemote host NAgent NEdgeGateway

What a fleet runs is the list of application profiles assigned to its agent profile. Click Assign profile and pick the profiles: predefined ones, your own, or a new one created inline. Every agent on that profile gets them, and the same list holds the bulk actions for each profile.

Assigning application profiles to an agent profile: Assign profile, picking the Gateway, Edge, and Mosquitto profiles, and the assigned list with the bulk actions for each profile

Then run the provisioning command on a new host. The agent registers itself, and the assigned applications install on their own. Each one is marked Auto-provisioned, and the Edge and Gateway entities and their credentials are created along the way.

Provisioning a new host: the agent profile’s One application per type strategy and its docker run command, and the new agent’s Gateway, Mosquitto, and Edge applications installed automatically with the Auto-provisioned origin

For a fleet that is already in the field, turn on Relate on Auto-Discovery for the Edge or Gateway profile before you connect the agents. Each discovered application that matches the profile’s template is attached to it and switches to the profile’s Docker Compose configuration, so the fleet comes under profile management without reinstalling anything.

Bulk actions: one action for every site

With profiles in place, a fleet operation is a single action. On the agent profile, pick an application profile and run a bulk restart, update, upgrade or delete. It targets every matching application across every agent that uses that agent profile.

Before anything runs, a pre-flight preview shows how many applications are eligible and why any are skipped, for example an application on a different version or one with an operation already in progress.

Bulk update of the Local Edge Profile: the Bulk Update action on the agent profile, the dialog with its pre-flight preview of total and eligible applications, and the run started on both applications

Each targeted application gets its own execution, with its own backup and its own rollback, so a failure on one host doesn’t stop the rollout on the others. You follow the whole rollout (done, error, running, pending) from one panel and can open any single host’s step-by-step progress.

Staged rollouts: staging first, then production

One application profile can be assigned to several agent profiles, which makes staged rollouts straightforward. Assign your Edge application profile to a staging and a production agent profile, bulk upgrade staging, verify, adjust the configuration if needed, then bulk upgrade production from the same profile.

Staged fleet upgrade with a shared application profileThe Factory Edge application profile is assigned to a staging and a production agent profile. The user upgrades the profile to the new template version, runs a bulk upgrade on the staging agent profile, verifies the result and adjusts the profile, then runs a bulk upgrade on the production agent profile.Factory EdgeApplication profile1. Upgrade to 4.4assignedassigneduser3. verify and adjustStaging agent profileAgent 1EdgeAgent NEdgeProduction agent profileAgent 1EdgeAgent NEdge2. Bulk upgrade4. Bulk upgrade

What changes with Remote Agent?

The same tasks, with and without Remote Agent

Task Without Remote Agent With Remote Agent
Reach a host behind NAT or a firewall VPN or inbound port per site Outbound connection from the agent
Deploy a Compose stack SSH in, copy files, run commands Pick a profile in the UI, or auto-install on provisioning
Upgrade ThingsBoard Edge Manual backup, migration and restart per host One upgrade action with volume backups and automatic rollback
Upgrade every site Repeat the above, host by host One bulk upgrade, staging first
Check the state of a site SSH in, docker ps, docker logs Status, metrics and live logs in the UI
Find sites that differ from the shared configuration Compare hosts one by one In Sync With App Profile column

What to plan for

  • Host requirements. Each host needs Docker and outbound access to the ThingsBoard gRPC port, the one ThingsBoard Edge uses (7070 by default).
  • Existing containers. Discovery works with Compose projects. Containers started another way are picked up once they carry the standard Docker Compose project and service labels.
  • The provisioning command. It is the same for every host in an agent profile and carries the profile’s provisioning credentials: anyone who has it can connect a new host to your ThingsBoard. Share it only with the people who set up hosts.

Conclusion

Your devices already report to ThingsBoard. With Remote Agent, the software running next to them does too: you deploy, upgrade and monitor it from the same place, on one host or across the whole fleet. Upgrades of ThingsBoard Edge and IoT Gateway include the database migration and roll back on failure, and a fleet that shares one configuration is provisioned with one command and upgraded with one bulk action.

Remote Agent is available today in ThingsBoard 4.4 and ThingsBoard Cloud.

How do you get started?

  1. Install the first agent. Go to Edge management > Agents > Add new agent and run the generated command on a host with Docker. See Install Remote Agent.
  2. Deploy or adopt an application. Add an Edge, Gateway or Generic application, or let the agent discover the ones already running. See Applications.
  3. Scale out with profiles. Create an agent profile, run its provisioning command on the rest of your hosts, and manage them with bulk actions.

Bring your remote hosts into ThingsBoard

FAQ

Remote Agent is a lightweight Docker container that runs on a remote host, connects outbound to ThingsBoard or ThingsBoard Cloud, and manages Docker Compose applications on that host. From the ThingsBoard UI you deploy, update, upgrade, restart, and delete those applications, watch host and container metrics, and stream live container logs, without opening SSH sessions for routine work. See the Remote Agent overview.

Any Docker Compose application. ThingsBoard Edge and IoT Gateway get first-class support with versioned templates, tracked upgrades, and database migrations. The Generic type runs any other Compose project: MQTT brokers, databases, or your own services. See Applications.

Remote Agent is available in ThingsBoard 4.4 and later and in ThingsBoard Cloud. Agents are managed under Edge management > Agents.

General-purpose tools such as Portainer manage Docker containers on any host. Remote Agent manages Docker Compose applications too, and adds what is specific to ThingsBoard: it finds new ThingsBoard Edge and IoT Gateway versions, runs their database migrations on upgrade with automatic rollback, and creates the Edge or Gateway entity with its credentials. Hosts are managed from the same ThingsBoard UI as your devices, and fleets are provisioned and upgraded through agent and application profiles.

No. The host needs only Docker: the agent runs as a Linux container on amd64, arm64, and 32-bit ARM, including in Docker Desktop on macOS and Windows. The agent talks to the Docker Engine API directly and applies the standard Docker Compose labels to every resource it creates, so managed applications still look like regular Compose projects to docker compose and other tools.

Install Remote Agent on the server with the docker run command that ThingsBoard generates for you. The agent connects back to ThingsBoard over an outbound gRPC stream; from then on every operation (install, update, upgrade, restart, delete, logs) is started from the ThingsBoard UI and executed by the agent locally. See Install Remote Agent.

No. The agent uses outbound connections only and opens no listening ports on the host. It needs outbound access to the ThingsBoard gRPC port (the same port ThingsBoard Edge uses, 7070 by default). TLS with public or custom CA certificates is supported.

The agent reconnects automatically with exponential backoff, and commands issued while it was offline are delivered after it reconnects. Every command step is idempotent and its completion is persisted on the agent, so after a reconnect or restart execution continues from the first unfinished step instead of starting over.

Yes. When the agent connects, it discovers the Docker Compose projects already running on the host and reports them as Discovered applications. You can manage them right away, and attach them to an application profile to bring an existing fleet under profile management and bulk actions, without redeploying anything.

No. The agent doesn't read Compose files. It groups containers into applications by their standard Docker Compose labels, so a container started any other way is managed once it carries the com.docker.compose.project and com.docker.compose.service labels. Volumes and networks need no labels. See Discover existing applications.

From the UI. When a newer agent image is published, ThingsBoard enables Upgrade agent. The agent pulls the new image, starts a replacement container, hands the host over, and removes the old one. If the handover does not complete, the old agent keeps serving. See Agent self-upgrade.

When a new Edge version is published, ThingsBoard marks the deployed application with Upgrade available. Click Upgrade, pick the volumes to back up, and confirm. The agent backs up the data, runs the Edge database upgrade scripts, starts the new version, and rolls back automatically if any step fails. See Upgrade an application.

The application returns to its previous state. Before an update or upgrade, the agent snapshots the application and backs up the selected volumes. If any step fails, it restores the volumes, recreates the previous containers, and marks the event as failed with the error from the failing step. Canceling a running operation rolls back the same way.

Yes. When an update or upgrade moves a service based on the official postgres image to a new major version, the agent detects the change from the data volume, backs it up, dumps the database with the old version, and restores it with the new one. The migration resumes after a crash and rolls back with the rest of the operation. See PostgreSQL major version migration.

Create an application profile with the shared Compose configuration and assign it to an agent profile with an auto-install provisioning strategy. Run the agent profile's provisioning command on each server. It is the same command for every machine. Each server registers as a new agent and installs the assigned applications automatically. See Agent profiles and auto-provisioning.

Use a bulk action. On the agent profile, pick the application profile and run a bulk restart, update, upgrade, or delete. Every matching application gets its own tracked execution with its own backup and rollback, so a failure on one host doesn't stop the rollout on the others. See Bulk actions.

Yes. Assign one application profile to a staging and a production agent profile. Bulk upgrade the staging fleet, verify the result and adjust the configuration, then bulk upgrade production with the same profile.

The In Sync With App Profile column shows whether every application still matches its application profile. An application drifts when someone edits its configuration directly or when the profile moves on; a single update or a bulk update brings it back in sync.