Ask us anything.

No. The model is outbound-only from the device to Front Desk. The site does not open inbound VNC, SSH, RDP, or admin ports.

No. Front Desk is a controlled remote-access path for specific devices and services: narrower than a VPN by design. VPNs join networks; Front Desk reaches devices. That narrower scope is easier to review, approve, and repeat across many customer premises.

No. Remote GUI is one access mode. Front Desk is aimed at field-device operations: GUI sessions, terminal access, local HTTP admin pages, logs, file transfer, commands, diagnostics, approval, and audit.

Those work for office users and attended support. Front Desk is aimed at fleets of devices installed in many places, usually with no one sitting at the keyboard.

Then the device becomes a public server, with the patching, password, and firewall exposure that brings. Front Desk exists so the device can stay private and still be reachable by the people responsible for it.

You could; plenty of fleets start there. But when no direct connection is possible, and behind customer firewalls it usually is not, each of those paths still ends up streaming through somebody's servers: the endpoint you poll, the broker you push through, or the relays a mesh or overlay network falls back to. Front Desk makes that stream the product. Its streaming system always carries the session and is designed and optimized for exactly that job: responsive interactive access, multiple simultaneous streams to the same device, and approval and audit applied to every stream on the way through. The path is protected end to end: TLS for transport, certificates and tokens for authentication and authorization. And if your security policy asks for more than that, our staff can build it as custom work.

No. Front Desk complements telemetry, billing, monitoring, and RMM systems as the secure device contact path they can rely on, not a replacement for them.

Yes. That is the design target. The customer network normally only needs to allow outbound traffic to approved Front Desk domains. No inbound rules, no address planning, no site-to-site VPN project.

The product direction covers GUI access, SSH or terminal-style access, local service access such as a device's web admin page, and database access. Actual support depends on the device operating system, agent version, and account configuration.

Yes. A streaming database session gives your native client (SQL Server Management Studio, MySQL Workbench, psql) a local port, and Front Desk carries the database protocol through the authenticated tunnel to a connector-local port on a Windows or supported Linux device. The .NET Linux connector and small C++ Connector Mini both support this streaming path. SQL Server, MariaDB, MySQL, PostgreSQL, or another TCP database protocol passes through unchanged and is never parsed. Credentials stay in your database client; Front Desk sees tunnel metadata and encrypted transport, not your connection string, and read-only access comes from the permissions of the database account you connect with.

Yes, on Windows and .NET Linux devices. A one-shot database command is queued through an account- and device-scoped API request, runs on the device through a named local ODBC profile, and returns a small structured result asynchronously. Commands are bounded by time and row limits on purpose: this path is for small operational reads, not bulk export. Linux requires unixODBC and a matching vendor driver. The ODBC profile and its credentials stay on the device, and read-only behavior is enforced by the database account you configure in it. Connector Mini does not execute one-shot database commands.

Front Desk supports Windows 11, Windows 10, and Windows 8.1 Embedded, plus Linux distributions and Yocto-built images on small boards: ARM, TI and NXP families, Orange Pi, RISC-V, and low-memory devices. Custom OS images are handled as part of deployment; our team does the agent, board, OS, packaging, testing, and rollout work the platform needs.

Yes. A customer contact, store manager, supervisor, or your own support lead can review an access attempt, seeing who is asking and for which device, and approve or deny it before the session starts.

Yes, optionally, per account. Front Desk can sample an audited session's screen and have a model review it after the session ends, or while it runs. The result is a written, plain-language account of what the operator did, kept in the customer portal with the rest of the session record.

A policy you write in plain words: what an operator may and may not do on your devices. The model reviews the captured screen frames against that policy, and anything the first pass is unsure about gets a second look from a stronger model before it is called a violation.

Only if you turn that on. By default a concern just produces a flagged report for a person to read. An account can opt into ending a session on a policy violation, and can choose what happens when auditing is not available, from proceeding with a warning to refusing the session entirely.

Then no live session is possible, and that is visible. The portal shows last contact time and current status, so support knows whether the device is reachable before anyone wastes a trip or a ticket.

If a device can wake and make outbound contact, it fits. A low-power controller can check in when it has Wi-Fi, report status or usage, receive supported actions, and sleep again. The portal always shows last contact and current reachability.

That is what the Front Desk Sidecar is for: a small attachable radio module that keeps presence, status, alarms, diagnostics, and recovery commands flowing over an independent long-range radio path to a hub, even when the normal network is the thing that failed.

It can be part of that workflow. A rental controller can report usage time or activity windows when it checks in. Front Desk is not the billing system itself; it provides the secure contact path and the reported device data your billing uses.

The model is a strong conceptual fit for cash machines, kiosks, field terminals, and other customer-prem devices. Exact deployment depends on the device OS, security policy, and access method needed.

It follows a zero-trust-style direction: authenticate the device, authenticate the user, avoid broad network trust, scope access to the session, and make access visible, without treating that as a formal certification claim. There is also a one-page security overview (PDF) made to hand to a security team.

An installer built for your account, not a generic bundle. Each deployment is packaged with the components your fleet uses: optional capabilities are included when you ask for them and left out when you do not. The package your security team scans is exactly the package that rolls out, with nothing dormant inside it.

SSO, RBAC, audit export, retention controls, APIs, SIEM integration, signed installers, device groups, agent update control, and private deployment options: the product direction expects those requests.

No. Businesses with remote device fleets are the primary audience, but individuals and small teams also use it for remote machines or boards where opening ports was never an acceptable answer.

Yes. We have staff who do this work: embedded Linux and board bring-up on small single-board computers, device software for Windows and Linux, and the Front Desk integration to go with it. We do the programming, the testing, and the rollout. Tell us what you need.

Yes, and we can do that work for you. If Front Desk needs to talk to your website, your customer portal, your back-office system, or an API you already run, our staff can build and test that integration rather than leaving it to your team. Start a conversation.