Does MQTT require Internet?

No. MQTT does not inherently require the public Internet. What MQTT requires is a reachable MQTT server — a broker — and a network connection between your clients and that broker that satisfies the protocol's requirements. Whether Internet access is actually necessary depends on the path to that broker and on the external services your deployment relies on.

A broker can run on the same device as your application, on a local Wi-Fi or Ethernet network, on a private leased line or WAN, behind a VPN, or as a managed cloud endpoint. Each of these is a legitimate MQTT deployment, and only some of them touch the public Internet.

The requirement is a reachable MQTT server, not a public Internet connection.

That distinction matters in practice. A system designed with the broker on the local network keeps working when the Internet goes down — it simply has no way to reach remote services. A system whose broker is reachable only through the public Internet loses access to that message bus when the Internet connection goes down. The protocol is the same in both cases; the architecture is not.

If your question is about offline operation for IoT generally, rather than MQTT specifically, see Can IoT Work Without Internet?. This article stays on the protocol layer.

What Does MQTT Actually Require?

The Publish/Subscribe Model in One Minute

MQTT is a publish/subscribe messaging protocol. It has three roles:

• Publishers send messages to a topic and do not know or care who receives them.
• Subscribers declare which topics they are interested in and do not know or care who is publishing.
• The broker sits in the middle. It receives every message, filters it against a subscription list, and forwards it to the interested clients.

Two consequences follow from this design. First, MQTT clients never connect to each other directly — all traffic passes through the broker. Second, the broker pushes messages to subscribers, so clients never poll for updates. That push model is one reason MQTT is so much lighter than HTTP for telemetry.

What the MQTT Specification Requires of the Network

At a practical level, an MQTT deployment needs:

1. An MQTT client and server that implement compatible protocol behaviour.
2. A network connection that satisfies MQTT's transport requirements.
3. Application-level configuration such as topics and QoS, plus authentication when the deployment requires it.

None of these requires the public Internet.

The transport requirement is worth stating precisely, because it is commonly overstated. The OASIS MQTT 5.0 specification defines a Network Connection as something provided by an underlying transport protocol that "provides the means to send an ordered, lossless, stream of bytes in both directions." The specification's abstract says the protocol "runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections."

MQTT does not require a specific transport. It requires a transport that keeps bytes ordered, lossless, and bidirectional.

In practice, MQTT commonly runs over TCP/IP, often with TLS on top. The specification also devotes a section to running MQTT over WebSocket. But the protocol is defined in terms of what the transport must guarantee, not in terms of one named protocol — which is why a strict reading of "MQTT needs TCP" is narrower than the standard itself.

Where the Confusion Comes From

Many explanations use "network connection" and "Internet connection" as if they were the same thing. There is a reason for that: many real-world MQTT deployments use cloud-hosted brokers, because that makes remote monitoring, multi-site aggregation, and fleet management straightforward.

In that architecture, the two requirements genuinely do coincide. Every client does need Internet access, because the broker is somewhere on the public Internet. It is an easy and understandable shortcut to describe the protocol that way.

Cloud-hosted brokers make the two requirements look identical. Architecturally, they are not.

The distinction is not academic. If you are building a factory-floor controller, a lab bench, or a home automation system where every participant is on the same network, the broker can be local — and the entire question of Internet access falls away.

Where Can the MQTT Broker Live?

The single most useful question to ask about any MQTT design is: where does the broker run? Once you answer that, the Internet question usually answers itself.

Same Device

The broker and the application run on the same machine, addressed as localhost. This is common in development, in single-purpose edge gateways, and in small self-contained systems. No external network of any kind is involved.

Local Network

The most common non-cloud arrangement: a broker running on a device inside your own network — a single-board computer, an industrial PC, a NAS, or a router. Clients reach it over the local network using an internal address.

This is the setup this article is really about. Everything stays inside the building.

Private WAN and Leased Lines

Brokers do not have to be local to be private. A device in one facility can talk to a broker in another facility over a private leased line, MPLS circuit, or private WAN. The two sites are physically far apart, but the traffic never touches the public Internet.

"Remote" does not automatically mean "public Internet." What matters is the path, not the distance.

VPN — Check the Underlay

VPNs are where this gets subtle, and where a lot of explanations go wrong. A VPN is a tunnel, not a network of its own. Its properties depend entirely on the underlying network — the underlay — that carries it.

• A site-to-site VPN over the Internet gives you an encrypted path between two sites, but the packets still traverse the public Internet. Public connectivity is required; encryption just protects the contents.
• A VPN running over a private circuit does not touch the public Internet at all.

So "it's behind a VPN" tells you nothing on its own about whether the Internet is required. You have to ask what the VPN runs on.

Cloud Broker

A managed MQTT service, or a self-hosted broker on a cloud virtual machine, is commonly reached through a public Internet endpoint — and in that case clients do need Internet connectivity. But “in the cloud” does not by itself make the public Internet mandatory: some hosted brokers can also be reached through private or dedicated connectivity.

Summary

Can MQTT Run Entirely on a Local Network?

Yes — and for a large class of applications it is the better choice.

What a Fully Local Setup Looks Like

Sensor / Device
        ↓
Local Wi-Fi or Ethernet
        ↓
Local MQTT Broker          ← Raspberry Pi, industrial PC, router or NAS
        ↓
Local Application Layer
        ↓
Automation Engine · Local Database · Local Dashboard

Every hop in that diagram stays inside your network. Devices publish to the broker; the broker forwards to whatever is subscribed — an automation engine, a local database, a dashboard. The loop closes locally.

Why No Public DNS Is Needed

On a local network you address the broker with a fixed internal IP, a local DNS record, or mDNS. The practical benefit goes beyond simplicity: using local addressing avoids delays caused by attempts to resolve an unreachable public DNS name while the Internet is down.

What Runs Where in Practice

• Smart home — devices, broker, and automation engine all on the home network; the phone app works while it is on the same Wi-Fi.
• Factory and workshop floors — brokers deployed inside the plant network, often alongside fieldbus equipment. MQTT typically sits above whatever industrial link the machines already use; for a comparison of the fieldbus options themselves, see CAN vs EtherCAT vs RS-485 vs UART.
• Lab and classroom — no dependency on an external network during a practical session.
• Remote and agricultural sites — a local gateway and local storage collect data; connectivity is dealt with separately.

A Note on Sizing

The broker itself is lightweight — a single-board computer handles a surprising number of clients. The resource that actually fills up is queued messages for disconnected clients on persistent sessions, and those queues are one of the main resources to watch when clients stay offline for long periods. Retained messages also consume broker storage, but they serve a different purpose. Configure session expiry and message expiry so that a device that never comes back cannot slowly exhaust the broker.

Which Parts of an MQTT System Depend on the Internet?

This is where precision matters, because "MQTT" and "an MQTT system" are not the same scope. The protocol core is offline-capable. The services you build around it may not be.

Core MQTT

Every item in that table is a property of the client-broker relationship. As long as those two can reach each other, none of them cares where the packets physically travel.

Surrounding Services

Note the firmware update rows. "OTA needs the Internet" is a common shorthand, and it is only true when the update server is hosted on the Internet. If you maintain a local update server, or distribute images on removable media, firmware updates are a local operation like everything else.

The protocol is offline-capable. What depends on the Internet is remote access, cloud services, external identity, and fleet-scale management.

What Happens When the Internet Goes Down?

The behaviour of an MQTT system during an Internet outage depends primarily on whether the broker and the services it relies on remain reachable.

Fully Local Deployments

Internet Outage
        ↕
   (no effect)
        ↕
Local Device → Local Broker → Local Automation

Core local MQTT messaging continues unchanged, provided that supporting dependencies such as DNS, time synchronization, authentication, and storage are also available locally. For the message bus itself, the outage is not an event.

Hybrid Deployments

Local Device → Local Broker → Local Automation      (keeps running)
                       ↓
                 Cloud Bridge                        (retries / pauses)
                       ↓
                 Cloud Services                      (unavailable)

In this architecture, local automation continues uninterrupted; only the cloud-facing functions stop — remote access, cloud dashboards, cloud analytics, and any OTA service that lives on the Internet.

Two MQTT features do the heavy lifting here. Persistent sessions let a client reconnect and find its subscriptions intact, so it does not have to rebuild its state. Queued messages hold data published while a subscriber was away, so that information is delivered on reconnection rather than lost. When persistent sessions, an appropriate QoS level, and queue limits are configured together, a connectivity gap becomes delayed delivery rather than immediate data loss — subject to session expiry, message expiry, and the broker's queue limits.

Cloud-Broker Deployments

MQTT messaging through that broker stops. Clients cannot reach it, so there is no message bus at all, and local device logic that depended on publishing or subscribing has nowhere to go. This is not a flaw in MQTT — it is the direct consequence of choosing a broker you can only reach across the public Internet. If that is your architecture, it is worth deciding up front how much downtime you can tolerate.

The Reconnection Sequence

Detect Loss of Connectivity
        ↓
Reconnect with Backoff
        ↓
Re-authenticate
        ↓
Resume Session (subscriptions restored)
        ↓
Deliver Queued Messages

Reconnect with backoff is the step that gets skipped most often, and the one that causes the most spectacular failures. If a thousand clients all lose connectivity at the same moment and all retry on a fixed short interval, they will hit the broker in synchronised waves and can keep it unavailable long after the underlying problem is fixed. Randomised, increasing backoff spreads those retries out.

Six Hidden Dependencies in Offline MQTT Systems

A local MQTT deployment looks self-contained. In practice there are six dependencies that, if left unhandled, will make an offline system behave as though it needed the Internet after all.

Why Time Comes First

Of these six, time synchronization is the one that wastes the most debugging hours, because it hides behind a misleading symptom.

When a device's clock is sufficiently wrong, TLS certificate validation can fail, because the certificate appears not yet valid or already expired. What you observe is a connection error — so the natural conclusion is that something is wrong with the network, the credentials, or the protocol configuration. The actual problem is none of those.

On an Internet-connected network this problem is often masked, because devices can synchronise against a public NTP service — though that masking is not guaranteed, since NTP may be blocked, misconfigured, or absent. In an air-gapped or offline deployment, that external source is unavailable unless you provide a local replacement, and the clock silently drifts.

In an offline deployment, fix the clock before you enable TLS. Otherwise you will debug certificates for a problem that is actually time.

Is Local MQTT Secure?

Running a broker on a private network removes one category of risk. It does not remove the rest, and it is easy to mistake the first for the whole.

Ports Are Conventions, Not Protocol Rules

These are conventional defaults, but they are configurable, and a broker is free to listen anywhere. Treat them as the ports you will probably find, not as rules the protocol imposes.

What matters more than the number is whether the listener is encrypted. Port 1883 is conventionally used for unencrypted MQTT, while 8883 is conventionally used for MQTT over TLS — but encryption is a property of the listener configuration, not of the port number. Unencrypted MQTT is tolerable on a network you fully control and problematic anywhere else.

Authentication and Access Control

MQTT has no built-in user model beyond what the broker implements. In practice, a secure broker combines:

• Authentication — username and password, mutual TLS with client certificates, or token-based schemes. MQTT 5 adds enhanced authentication through the AUTH packet, which supports challenge-response exchanges and re-authentication on an established connection. Implementations may also delegate to external authentication systems, and may carry tokens such as OAuth tokens.
• Authorization — an access control list restricting which clients may publish or subscribe to which topics. Without appropriate access controls, authenticated clients may receive broader publish or subscribe permissions than intended.

Why "Unreachable" Is Not the Same as "Secure"

An internal MQTT deployment is not exposed to the public Internet, so direct exposure to Internet-wide scanning and opportunistic attacks is greatly reduced. That is a real benefit.

It is not the same as being secure. If an attacker does get a foothold somewhere inside the network — a compromised workstation, a device with default credentials, a poorly configured Wi-Fi access point — then traffic on port 1883 is readable and modifiable, and a broker without access controls can expose far more of your system than intended.

Being unreachable from the Internet removes one class of attacker. It does not encrypt your traffic or make your clients trustworthy.

Isolate the Broker

If the broker can be placed in its own network segment, with its reachability to other business systems restricted, then a compromised device can talk to the broker without automatically gaining access to everything else on the network. This costs little and removes a great deal of blast radius.

Local MQTT vs Cloud MQTT

Neither architecture is automatically the right choice. A single-site deployment with privacy requirements and a good local administrator is usually better served by a local broker. A fleet spread across a dozen countries is usually better served by a cloud broker, and accepts the connectivity dependency as the cost of that reach.

The hybrid pattern — local broker for control, cloud bridge for aggregation — exists precisely because most real systems want some of each.

How to Build MQTT That Works Without Internet

1. Decide where the broker lives. Everything else follows from this. Local, private WAN, or cloud; the rest of the design is constrained by the answer.
2. Give every client a predictable address. Fixed internal IPs, local DNS, or mDNS. Avoid anything that requires a public domain lookup to establish a connection.
3. Fix time before you enable TLS. A local NTP or chrony server, or a real-time clock on the device. Do this before you debug a single certificate.
4. Choose QoS per topic, not globally. Telemetry usually tolerates QoS 0 or 1; control commands that must arrive justify QoS 1 or 2. Remember that QoS 2 provides exactly-once delivery on an MQTT delivery hop; it does not make your end-to-end application logic idempotent. If a command would be harmful when applied twice, handle that in the application.
5. Use retained messages for state, and Last Will for failure. A retained message means a new subscriber learns the current state immediately instead of waiting for the next update. A Last Will means the system learns about an unexpected disconnect.
6. Plan reconnection backoff and queue limits. Randomised, increasing backoff on the client side; session expiry and message expiry on the broker side so that queued data cannot grow without limit.
7. Keep storage and dashboards local. If the data and the visualisation both live on the local network, an Internet outage does not remove your ability to see what is happening.
8. Decide what happens when the Internet returns. Should buffered data be uploaded, discarded, or merged? How do you handle duplicates and conflicts? Deciding this in advance is far easier than debugging it afterwards.

A checklist for an offline MQTT deployment:

• ☐ The broker runs locally and starts automatically on boot
• ☐ Clients use fixed addresses rather than public hostnames
• ☐ Time synchronization is in place and verified
• ☐ Certificates are issued by a local CA, with a renewal and rotation process that works offline
• ☐ The QoS level of each topic was chosen deliberately
• ☐ State topics use retained messages; failure detection uses Last Will
• ☐ Queued messages have both a size limit and an expiry policy
• ☐ The system has survived at least one deliberate disconnection test

MQTT-SN

MQTT-SN (MQTT for Sensor Networks) extends the MQTT model to embedded devices on non-TCP/IP networks, such as Zigbee-style wireless sensor networks — the goal being to reach devices that TCP/IP infrastructure cannot. It retains the core publish/subscribe concepts, including retained messages and Will functionality, but the network architecture and wire-level behaviour differ from standard MQTT. It can operate over datagram-oriented or non-TCP/IP transports, with UDP being one common option rather than the only one. When an MQTT-SN deployment is bridged into a standard MQTT network, a gateway can connect the MQTT-SN side to an MQTT server. Note that MQTT-SN 2.0 is still an OASIS working draft as of 2026, with the transport discussion ongoing, so treat its details as provisional. For this article's question, the answer is unchanged: the MQTT-SN server or gateway and the MQTT broker can all remain local.

FAQ

Does MQTT require Internet?

No. MQTT requires a reachable MQTT server. When that server is on your local or private network, no public Internet connection is involved at all. Internet access becomes necessary when the broker is only reachable across the public Internet, or when the system depends on an Internet-hosted service.

Can MQTT work on a local network only?

Yes. A broker on the local network with clients on that same network is a complete, self-sufficient MQTT system as far as messaging is concerned. This is covered in more depth, along with other approaches to offline operation, in Can IoT Work Without Internet?.

Does MQTT need Wi-Fi?

No. MQTT needs a network connection that satisfies its transport requirements. Ethernet, a private circuit, and a VPN all qualify. Wi-Fi is simply one common way to provide that connection, and it is not part of the protocol.

Does an MQTT broker have to be in the cloud?

No. A local broker is a common and often better choice for single-site deployments. It can remove the public-Internet dependency from core MQTT messaging, reduces latency, and keeps data on site.

Does MQTT use TCP or UDP?

MQTT is most commonly run over TCP. The specification does not mandate one specific transport — it requires an ordered, lossless, bidirectional stream of bytes, and any transport that provides that qualifies. UDP alone does not, which is why MQTT-SN exists separately for datagram-oriented sensor networks.

Does MQTT work without any network at all?

It depends. A client and a server must have a connection between them that meets the protocol's requirements. Running the broker on the same device, addressed as localhost, involves no external network — but a completely networkless MQTT system is not possible.

Is MQTT secure without Internet access?

Not automatically. Removing public reachability reduces exposure, but it does not encrypt traffic or authenticate clients. TLS, authentication, and topic-level access control remain important, and encryption depends on how the listener is configured rather than on the port number.

What happens to MQTT messages when the Internet goes down?

It depends on the broker's network path and on supporting services. With a fully local broker and local dependencies, core MQTT messaging can continue normally. With a broker that is reachable only through the public Internet, MQTT messaging through that broker stops. In a hybrid design, local messaging can continue while cloud-facing functions become unavailable.

Can a Raspberry Pi be an MQTT broker?

Yes. A broker is lightweight enough to run comfortably on a single-board computer, which makes it a very common choice for a local broker in home automation, education, and small industrial deployments.

Is MQTT-SN a replacement for running MQTT over the Internet?

No. MQTT-SN is a complementary variant aimed at constrained devices on non-TCP/IP networks. It needs a gateway to connect into a standard MQTT broker, and its purpose is reachability, not replacing Internet-connected MQTT.

Conclusion

MQTT does not inherently require the public Internet.

It requires a reachable MQTT server and a network connection to it that meets the protocol's transport requirements. That connection can stay on the same device, on a local network, or over a private WAN, or it can traverse the public Internet. A VPN does not answer the question by itself: whether Internet access is required depends on the VPN's underlying network. What remains outside the protocol is a separate question — whether your system also relies on remote access, cloud services, or an external identity provider.

The practical rule follows from that: keep the local operation and the Internet-dependent services separate. Run the broker and the control loop on your own network, and treat cloud connectivity as an enhancement rather than a foundation. That way, losing the Internet does not mean losing the MQTT system itself.

Build a Local MQTT Broker on a Raspberry Pi

A single-board computer is enough to host a local MQTT broker for a home, a lab, or a small workshop — and to keep your automation running independently of any cloud service.

The Raspberry Pi 5 is offered in 2GB, 4GB, 8GB, and 16GB RAM variants, which gives you room to run a broker alongside a local database, an automation engine, or a dashboard on the same machine.

Offline operation depends on your software and network configuration; these boards are development platforms, not preconfigured complete MQTT systems.

View Product