Skip to main content

Cloud Gateway

The Communication Gateway can be deployed in two ways. In addition to the physical Gateway installed on the customer's network (described in the Overview), the gateway service can also run in the cloud, reaching the site's devices through an encrypted VPN tunnel.

Both models are active, and the choice is up to the customer, based on the characteristics of each project.

Why this model exists​

Accelero is a SaaS system and communicates with devices over MQTT, with the connection always initiated by the device toward the cloud. This design avoids exposing the customer's network: no public IP, no port forwarding, and no service published on the internet.

Facial readers, however, do not speak MQTT. They expose an HTTP API on the local network. That is why the Gateway exists: it sits where the devices are and translates MQTT into HTTP.

Delivering that component as a dedicated computer at the site brings costs and risks that do not belong to the software: device acquisition cost, power consumption, rack space, and all the typical hardware failures in the field, such as memory card corruption, power supply defects, and accidental shutdown. Most of these incidents require an on-site technician visit.

In the cloud model, that computer no longer exists at the site. The connectivity role is taken over by a network device that is already installed in most projects: the MikroTik.

How it works​

The MikroTik establishes a WireGuard tunnel between the site's network and the cloud infrastructure. Inside this private tunnel, the gateway service reaches only the authorized devices of that site, sending enrollments, photos, facial templates, cards, and synchronization commands.

Three characteristics define the model:

  • The MikroTik initiates the tunnel, from the inside out. The customer needs no static public IP and no inbound port forwarding. It works on virtually any type of link, including behind carrier-grade NAT.
  • Readers remain on private IPs. No device is reachable from the internet. Access happens exclusively through the tunnel, with firewall rules restricting communication to the required addresses and services.
  • Integration logic stays in the gateway service. The MikroTik does not process enrollments or access rules: it is the secure connectivity and routing point. To Accelero, the gateway behaves exactly as before, appearing normally on the gateways screen with status, version, and keepalive.

The gateway did not disappear, it moved​

This point is worth stressing, because it is the most common misunderstanding about the model.

The Gateway has always played three roles: transport (secure communication with the cloud), integration (translating MQTT into HTTP, handling queueing, retries, and error handling), and execution (talking to the reader over its REST API).

The MikroTik takes over transport only. It is a network device: it has no message queue, does not handle an unavailable reader, does not retry, and keeps no integration history. Integration and execution remain the responsibility of the gateway service, which now runs in the cloud with the same behavior as before.

That is why the model is not "the cloud calling the reader directly through the tunnel". It is the same gateway as always, in the same logical design, simply hosted on Iongrade's infrastructure instead of the customer's rack.

Why WireGuard​

WireGuard is the VPN protocol recommended for this scenario, and MikroTik itself describes it as simpler, faster, and more performant than OpenVPN. In practice this means a smaller and less error-prone configuration (no certificates or PKI to maintain), near-instant reconnection on links that fluctuate, and lower CPU usage on the router, which matters on entry-level models.

What changes for the customer​

Physical GatewayCloud Gateway
Dedicated device at the siteYes (Orange Pi or mini PC)No
Required network equipmentNone specificMikroTik with WireGuard support
Equipment costOne Orange Pi or mini PC per siteMikroTik, usually already installed and cheaper
Additional power consumptionYesNo
Gateway hardware failurePossibleNot applicable
Maintenance and updatesRemote when possible, on-site when notRemote, performed by Iongrade
Exposure of the customer's networkNoneNone
Internet dependencyYesYes

Site requirements​

To operate in the cloud model, the site needs:

  • MikroTik with a RouterOS version that supports WireGuard, sized for the project's traffic volume.
  • Stable internet link, with upload and download bandwidth suited to the device fleet. Sending photos to the readers now travels over the internet.
  • Facial readers on static IPs on the local network, documented in the project.
  • A route between the readers' network and the MikroTik. If the readers use the MikroTik as their default gateway, this requirement is already met.
Readers in Direct Mode require extra attention

In online validation mode (Direct Mode), it is the reader itself that queries the server on every read to decide whether to grant passage. In that case communication also flows from reader to cloud, and each device must be configured to point to the gateway's address inside the VPN.

If this adjustment is not made, the symptom is distinctive: enrollments synchronize normally and only access release fails, which is often misdiagnosed as a reader defect.

Check the homologated equipment matrix to confirm the operation mode of each device.

Security​

  • All traffic is encrypted between the cloud and the site's network, including photos and biometric templates, which are sensitive personal data. See LGPD and Security.
  • No ports are opened at the site. There is no port forwarding and no device published on the internet. This is a significant improvement over the practice, still common in the market, of exposing the facial reader's port to reach it remotely.
  • Restricted reach. The tunnel rules allow communication only with the site's authorized devices, not with the entire local network.
  • Isolation between customers. Each site has its own identification, encryption keys, VPN addressing, and routing and firewall rules. One site cannot reach another site's network or devices.

Behavior during an internet outage​

The behavior is the same in both models, because in both the cloud is what makes the decisions:

  • Enrollment management: readers keep granting access normally, using the already synchronized database. Enrollments and changes made during the outage stay pending and are applied as soon as communication returns.
  • Online validation (Direct Mode): release depends on querying the server, so it is unavailable while the internet is down, exactly as it already was with the physical Gateway.

During the outage, all readers at the site appear offline at once in Accelero. This helps with diagnosis: a single reader offline points to the device, the whole site offline points to the link or the tunnel.

When to prefer each model​

Cloud Gateway is recommended when:

  • the site already has a MikroTik and a stable link;
  • there is a history of failures or maintenance difficulties with the local device;
  • the customer wants to reduce active equipment in the rack and power costs;
  • the fleet is spread across several sites, and standardizing remote maintenance brings operational gains.

Physical Gateway is recommended when:

  • Accelero is on-premises and the server sits on the customer's own network;
  • the site has no MikroTik and no plans to install one;
  • the link is unstable or lacks bandwidth for the synchronization volume;
  • there is a contractual requirement that access control traffic must not cross the internet.
Migration

Migrating a site from the physical Gateway to the cloud gateway is performed by the Iongrade team, with the tunnel validated before the switchover. The physical Gateway is only powered off after cloud communication has been confirmed. At sites with devices in Direct Mode, each reader must be reconfigured during the migration.

Next Steps​