How Remoteler Works

Secure Access for SQL & NoSQL Databases

Remoteler implements native database wire protocols for supported SQL & NoSQL databases with certificate-based authentication, RBAC, and database activity auditing features.

The basics

Remoteler Database Access solves the problem of consolidated access to multiple database instances running behind NAT across multiple cloud providers, datacenters or even on edge networks. Remoteler enforces the following access best practices:

  • Certificate-based authentication tied to user’s identity. Certificates expire automatically and this removes the need for shared secrets, passwords, etc.
  • There is a single sign-on process (SSO) which is tied to an organization’s identity provider such as Google Apps, Active Directory, Okta, or any other IAM with SAML or OIDC support.
  • Remoteler keeps a detailed audit log of all database activity across all instances.


To better understand the concepts used in the diagram below, we recommend taking a look at Remoteler Basic Concepts first. The architecture diagram assumes that database instances and clients can be located on different private networks, and only Remoteler Proxy offers a publicly accessible endpoint:

Remoteler Database Access is simple because all Remoteler components in the diagram are implemented in a single dependency-free executable which can run as a Linux daemon or in a Kubernetes pod.

  • Clients on the left use tsh command to authenticate and receive short-lived certificates. tsh automatically configures psql and mysql commands, enabling smooth user experience.
  • Remoteler Proxy Service accepts client connections, forwards authentication requests to identity providers, serves a web UI for audit & administrative purposes. Remoteler Proxy Service is publicly accessible, highly available and has a DNS address like
  • Remoteler Auth Service is a certificate authority (CA) which issues short-lived certificates to clients and also keeps the audit log of client sessions. 
  • Remoteler Database Service is deployed on the same network as the target databases. It maintains a permanent encrypted reverse tunnel to the proxy. The tunnel is used to encapsulate the incoming client connections. The tunnel allows access to databases behind NAT without opening any network ports.

Supported Protocols

Remoteler Database Access currently supports the MariaDB, Microsoft SQL Server, MongoDB, MySQL, PostgreSQL and Redis protocol.

For PostgreSQL and MySQL, the following Cloud-hosted versions are supported in addition to self-hosted deployments including Amazon RDS, Amazon Aurora (except for Amazon Aurora Serverless, which doesn’t support IAM authentication), Amazon Redshift, Google Cloud SQL, and Azure Database.

User Experience

Let’s consider what happens when a client needs to connect to a database.

  1. The client issues tsh login command. This command triggers the Single Sign-On (SSO) sequence with an identity provider (Remoteler offers a built-in database of users too). After a successful authentication, tsh receives a short-lived x.509 certificate and stores it on a client side, usually in ~/.tsh directory.
  2. The client must select a database it wants to connect to via tsh db login. This command will configure the database client such as mysql or psql with a Remoteler Proxy Service address and the selected database. The list of available databases can be printed with tsh db ls command.
  3. The client uses database client’s, such as psql or mysql as usual, to connect to the selected database.
  4. Remoteler Proxy Service accepts the connection, and dispatches it to the appropriate Remoteler Database Service based on the routing information encoded in the client certificate, over the reverse tunnel.
  5. Remoteler Database Service authenticates the connection, performs an authorization check, and then establishes the connection to the database.
  6. Remoteler Database Service begins proxying traffic between the user’s database client and the database. Additionally, it interprets the database wire protocol messages and submits events to the Remoteler audit log

Audit log

The audit information is collected by the Remoteler Auth Service. Remoteler logs the following information:

  • Access events such as authentication attempts, connected/disconnected sessions, and so on.
  • SQL queries executed by clients.

The location of the audit log is configurable. The following locations are supported:

  • Local storage, i.e. on any Linux file systems.
  • Cloud storage such as DynamoDB, Google Firebase and others.
  • Amazon S3.

Remoteler relies on the storage back-ends to provide the encryption at rest capabilities. Remoteler uses a documented JSON format for the audit log events, making it easy to export audit log events into external SIEM tools or general purpose solutions such as Splunk or Elastic.

Example of a JSON event recorded in Remoteler Audit Log:

To learn more about Database Access, take a look at Remoteler Documentation.

Try Remoteler Today!