Self Hosting

Visual DB is available as a Software-as-a-Service (SaaS) solution, but can also be self-hosted on your own infrastructure if you prefer. You can run it on your laptop for personal projects, or deploy it on your intranet or in the cloud for business use.

The only prerequisite is Docker. Visual DB service is compatible with Windows, Linux, and macOS, and supports x64 (Intel/AMD) and ARM64 processors, including Apple Silicon.

When Should You Consider Self-Hosting?

When you self-host, your data never leaves your infrastructure. If this is important to you, then consider self-hosting. Also, if you want to connect to databases on your intranet, self-hosting is the only option.

Generate Script to Start Docker

To run Visual DB service on your Windows, macOS, or Linux computer visit https://app.visualdb.com/self-host to generate a script. The script is customized for you and contains secrets such as encryption keys that must be kept safe and confidential. The script cannot be regenerated, so make sure to back it up.

The script simply sets up some environment variables and starts Docker with the right image.

These are some of the environment variables set up by the script:

VDB_HOST_ID This is a string that uniquely identifies your host.
VDB_API_KEY This is a string that authenticates your host.
VDB_ENCRYPTION_KEY This is a key used to encrypt database passwords.
VDB_TOKEN_SECRET This is a secret used to generate authentication tokens for users logging into your host.

Be aware that the VDB_HOST_ID value cannot be used by multiple Visual DB instances. Running multiple instances with the same VDB_HOST_ID will cause cache consistency issues.

Keeping Your Database Secure

If your database is hosted in the cloud, restrict access to specific IP addresses to ensure connections only come from trusted sources.

For additional security, consider setting your own values for VDB_ENCRYPTION_KEY and VDB_TOKEN_SECRET environment variables. Use this simple Python script to generate your own values. These keys never leave your computer and provide an additional layer of security.

Always use HTTPS

When deploying your application, ensure all traffic is encrypted using HTTPS. Consider using a service like Azure App Service which provides built-in SSL termination, automatically managing certificates and encryption. This eliminates the complexity of manually configuring and maintaining SSL certificates while ensuring all data transmitted between users and your application remains secure.

On your intranet you can use Caddy to support HTTPS. Ready-to-use scripts are available here, just fill in your environment variables in the .env file!

Hosting Visual DB Service in the Cloud

Visual DB was designed from the ground up to be easily cloud-hostable. On Azure, create an App Service instance with the Visual DB docker image. On AWS use the Lightsail container service. On GCP use Cloud Run. In all cases the four environment variables mentioned above must be set on the container.

The Artifact Service

As you use Visual DB, you generate artifacts such as queries, form specifications, and report specifications.

A challenge when running containers, especially in the cloud, is how to permanently store these artifacts. While containers have local storage, this storage is typically ephemeral and lost when the container is restarted. Major cloud vendors such as Azure, AWS, and GCP have made it easy to run containers but have not solved the problem of simple artifact persistence across container restarts.

Visual DB Artifact Service solves this problem by storing artifacts on behalf of your container. As long as the environment variables VDB_HOST_ID and VDB_API_KEY are set on the container, your Visual DB instance will be able to store artifacts using the Artifact Service.

The variables can be generated by visiting https://app.visualdb.com/self-host.