Connect a direct database
PostgreSQL, MySQL, SQL Server, Azure SQL, or Oracle. Pick your database below — the DashboardFox form is the same for all four, with slightly different setup depending on where your data lives.
By the end of this lesson
- A live, queryable connection to your database
- An app your reports and dashboards can be built on
You'll need
- Connection details (host, database, user, password) from your DBA
- Network path from DashboardFox to your database
- Admin role in DashboardFox
Background
This page walks you through connecting a PostgreSQL database to DashboardFox. The video uses Supabase as the example, but the same four pieces of info work for any Postgres host — AWS, Google Cloud, Heroku, DigitalOcean, Neon, or your own server.
Postgres is a popular open-source database. If your data lives in Postgres, you're in the right place.
Stuck anywhere on this page? Email team@dashboardfox.com. We'll help you sort it out.
Before you start
- Your Postgres connection details — host, database name, username, password. (We'll show you where to find these in step 1.)
- About 5 minutes.
- Admin access in DashboardFox (or the App Builder permission).
Do it
-
Find your connection details
You need four things from your database host: host (the address), database (the name), user, and password. Where you find these depends on who hosts your database.
Using Supabase (the video example)
In your Supabase project, click Project Settings → Database. The host and user are listed under Connection info. The database name is always
postgreson Supabase (not your project name). Use the password you set when you created the project. If you've forgotten it, you can reset it on the same page.Using AWS RDS or Aurora
Open the AWS console and go to RDS → Databases → click your database. The Endpoint is your host. The database name and master username are on the Configuration tab. The password is the one you set when you created the database. Make sure Public accessibility is set to Yes if you're connecting from outside AWS.
Using DigitalOcean Managed Databases
In the DigitalOcean control panel, open Databases → click your Postgres cluster. The host, port, database name, user, and password are all listed under the Connection details dropdown. Pick the Public network option to get the address you'll use from outside their network.
Heads-up: DigitalOcean uses a non-standard port (
25060). See step 3 for how to handle that.Using Heroku Postgres
In your Heroku app, open the Resources tab and click your Heroku Postgres add-on. Go to Settings → View Credentials. Heroku gives you all four values plus a non-standard port — see step 3 for how to handle the port.
Using another managed provider (Azure, Google Cloud, Neon, Render, Vultr Managed, ElephantSQL, Aiven, etc.)
The pattern is the same everywhere: open your database in the provider's console, look for a tab or button labeled Connection details, Credentials, Connect, or Connection info. The four values are there.
Provider-specific notes:
- Azure Database for PostgreSQL: server name looks like
myserver.postgres.database.azure.com. - Google Cloud SQL: use the Public IP address from the Overview tab; you'll also need to allow your DashboardFox IP in Connections → Networking.
- Neon: if you use branches, each branch has its own connection string — pick the one for the branch you want to report on.
- Render: use the External Database URL, not the internal one.
Not finding it? Email team@dashboardfox.com with your provider name — we'll point you to the right page.
Self-hosted (Vultr, Linode, Hetzner, your own server)
If you installed Postgres yourself on a VPS or your own server, you set the credentials when you installed it. The host is your server's public IP or domain. The database name, user, and password are whatever you configured during setup.
You'll also need to make sure Postgres is configured to accept remote connections — check
postgresql.conf(listen_addresses = '*') andpg_hba.conf(an entry that allows your DashboardFox IP). Whoever set up the server should know this; otherwise email us. - Azure Database for PostgreSQL: server name looks like
-
Allow DashboardFox through your firewall
A firewall is a security gate that blocks unknown visitors. Most cloud-hosted databases have one on by default. You'll need to add DashboardFox's IP address to the allow list so we can reach your data.
Find your DashboardFox IP: in DashboardFox, go to Settings → Integrations → Firewall Allow List. Copy the IP shown there. The address is different depending on whether your DashboardFox instance is hosted in our US or EU region — pulling it from your own settings means you always get the right one.
Where to add it in Supabase
Project Settings → Database → Network restrictions. Add the IP and save. Supabase allows all IPs by default — if that's still on, you can skip this. If you've already restricted access, the IP needs to be on the list.
Where to add it in AWS RDS
Open your database in the RDS console → Connectivity & security tab → click the VPC security group → Inbound rules → Edit inbound rules. Add a rule: type PostgreSQL, source Custom, and paste your DashboardFox IP with
/32on the end (so if your IP is52.10.20.30, enter52.10.20.30/32).Where to add it in DigitalOcean
Open your database cluster in the DigitalOcean control panel → Settings tab → Trusted sources. Click Edit, paste your DashboardFox IP, and save. By default, DigitalOcean allows all IPs through — if you haven't restricted yet, you don't have to do anything here. (We'll come back to it in "Make it real" below.)
Where to add it in another managed provider
The pattern is the same: find a section called Network, Networking, Firewall, or Trusted sources in your provider's console.
- Azure Database for PostgreSQL: the database resource → Networking → Firewall rules. Add a rule with the same start and end IP. Don't forget to also enable Allow public access if it's off.
- Google Cloud SQL: the instance → Connections → Networking → Add a network.
- Heroku: nothing to do — Heroku Postgres is open to the internet by default.
- Neon, Render, Vultr Managed: usually a Network or IP allow list section in the database settings.
Where to add it for self-hosted (Vultr VPS, Linode, Hetzner, your own server)
This is whatever firewall your server runs. Common options:
- Linux
ufw:sudo ufw allow from <your-DBF-ip> to any port 5432. - Linux
firewalldoriptables: similar rule for port 5432. - Cloud provider firewalls (Vultr, Linode, Hetzner all have a separate firewall layer in their consoles): allow inbound TCP from your DashboardFox IP on port 5432.
- Windows Firewall: an inbound rule for TCP 5432, scoped to your DashboardFox IP.
You'll also need to make sure Postgres itself accepts the connection — see the self-hosted note in step 1.
-
Enter the details in DashboardFox and test
In DashboardFox, go to Settings → Integrations → New connection. Pick PostgreSQL as the type, then fill in the four values from step 1. Click Test connection.
If the test passes, save it. The connection becomes a new app in DashboardFox — that's the term for a configured data source you build reports on.
What if my Postgres uses a non-standard port?
DashboardFox uses port 5432 automatically. If your provider uses a different port (Heroku, DigitalOcean, and some self-hosted setups do), open the Additional settings accordion below the form and add
Port=NNNN;in the Additional connection string parameters field. ReplaceNNNNwith your actual port number. -
Grant access to your new app
Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.
Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.
Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.
-
Build your first app
You're connected and you have access. Now you shape the data model — pick which tables you want, name fields in plain English, define relationships. That's a separate lesson because it deserves its own walkthrough: Building your first app →.
Come back here if you ever need to update the connection itself (password changed, host moved, etc.).
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
The connection above works. Before you let your team or customers loose on it, two things are worth doing.
Use a read-only database user
The credentials you used in step 1 might be your admin login — which means DashboardFox could in theory write to or delete from your database. It won't (DashboardFox only reads), but it's still safer to use a dedicated user that can only read.
Show the SQL to create one
-- Run this in your Postgres console as a superuser
CREATE USER dashboardfox_reader WITH PASSWORD 'pick-a-strong-one';
GRANT CONNECT ON DATABASE your_database TO dashboardfox_reader;
GRANT USAGE ON SCHEMA public TO dashboardfox_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dashboardfox_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO dashboardfox_reader;Then go back to Settings → Integrations, edit your connection, and swap the user and password to the new one.
Restrict your firewall to DashboardFox's IP
If you allowed all IPs through your firewall in step 2 just to get going, narrow it down now. Only your DashboardFox IP needs through (you'll find it in Settings → Integrations → Firewall Allow List). Everything else stays blocked. Same place you added the IP in step 2 — just remove the wide-open rule.
Need stored procedures, direct SQL, or to adjust query timeouts? See Advanced data source settings.
If you're stuck
Most connection problems fall into one of these. Click the one that matches the error you're seeing.
I see "Connection refused" or "could not connect to server"
The firewall is blocking us. Go back to step 2 and check the IP is on the allow list. On AWS RDS specifically, double-check the security group is the one actually attached to your database (it's possible to edit a different one by mistake).
I see "password authentication failed for user"
Either the username or password is wrong, or both are right but the user isn't allowed to connect from outside. Reset the password in your provider's console, paste it fresh into DashboardFox (no extra spaces), and test again.
I see "database does not exist"
The database name field doesn't match a real database. Check the spelling. On Supabase, the database is always postgres (not your project name). On other providers, it's whatever you named it when you created it.
I see "could not translate host name"
The host address is wrong or has a typo. Hosts usually look like db.abcdefg.supabase.co or mydb.abc123.us-east-1.rds.amazonaws.com — long, with dots. Don't include https:// or any port number.
The connection saved fine, but I can't see the app in App Builder
You skipped step 4 (Grant access). Go to Settings → Security → Apps, find the app, click Edit, assign yourself App Builder, and save. This is the most common first-day surprise — you're not doing anything wrong.
None of these match my error
Email team@dashboardfox.com with a screenshot of the error and your provider name (e.g., "Supabase"). DashboardFox passes your provider's exact error message back unchanged — copy the whole thing and we'll help you decode it. Same business day reply.
Background
This page walks you through connecting a MySQL database to DashboardFox. The video uses AWS RDS as the example — by far the most common cloud MySQL setup. The same four pieces of info work for any MySQL host — Azure, Google Cloud, DigitalOcean, Heroku, or your own server.
MariaDB works through this lesson too. It's wire-compatible with MySQL and uses the same DashboardFox driver.
Stuck anywhere on this page? Email team@dashboardfox.com. We'll help you sort it out.
Before you start
- Your MySQL connection details — host, database name, username, password. (We'll show you where to find these in step 1.)
- About 5 minutes.
- Admin access in DashboardFox (or the App Builder permission).
Do it
-
Find your connection details
You need four things from your database host: host (the address), database (the name), user, and password. Where you find these depends on who hosts your database.
Using AWS RDS (the video example)
Open the AWS console and go to RDS → Databases → click your MySQL database. The Endpoint on the Connectivity & security tab is your host. The database name and master username are on the Configuration tab. The password is the one you set when you created the database.
Important: the database needs Public accessibility set to Yes if you're connecting from outside AWS. Edit the database to turn this on if it's currently No.
Using Azure Database for MySQL
In the Azure portal, open your MySQL server. The Server name on the Overview page is your host (looks like
myserver.mysql.database.azure.com). The admin username is also there. The database name is whatever you created on the server — pick the one you want to report on.Using Google Cloud SQL for MySQL
In the Google Cloud console, open SQL → click your instance. Use the Public IP address from the Overview tab as your host. Database name and users are on the Databases and Users tabs. You'll also need to allow your DashboardFox IP under Connections → Networking.
Using DigitalOcean Managed Databases
In the DigitalOcean control panel, open Databases → click your MySQL cluster. Host, port, database name, user, and password are all listed under the Connection details dropdown. Pick Public network for the address you'll use from outside.
Heads-up: DigitalOcean uses a non-standard port (
25060). See step 3 for how to handle that.Using Heroku (ClearDB, JawsDB, or similar MySQL add-on)
In your Heroku app, open the Resources tab and click your MySQL add-on. The credentials page gives you the four values plus a non-standard port. ClearDB and JawsDB connection details are formatted as a single URL — extract host, database, user, and password from it.
Using another managed provider (Aiven, PlanetScale, Vultr Managed, etc.)
The pattern is the same: find a section called Connection details, Credentials, or Connect in your provider's console. The four values are there, plus the port if it's non-standard.
Not finding it? Email team@dashboardfox.com with your provider name — we'll point you to the right page.
Self-hosted MySQL or MariaDB (Vultr VPS, Linode, Hetzner, your own server)
If you installed MySQL or MariaDB yourself, you set the credentials at install time. The host is your server's public IP or domain. Default port is
3306.You'll also need to make sure MySQL accepts remote connections — check
my.cnfforbind-address = 0.0.0.0(or your DashboardFox IP) and that the user is allowed to connect from outside (the user's host part, e.g.,'reader'@'%'). Whoever installed it should know. -
Allow DashboardFox through your firewall
A firewall is a security gate that blocks unknown visitors. Most cloud-hosted databases have one on by default. You'll need to add DashboardFox's IP address to the allow list so we can reach your data.
Find your DashboardFox IP: in DashboardFox, go to Settings → Integrations → Firewall Allow List. Copy every IP you see there (you might see one or several — add them all). The addresses depend on whether your DashboardFox instance is hosted in our US or EU region.
Where to add it in AWS RDS (the video example)
Open your database in the RDS console → Connectivity & security tab → click the VPC security group → Inbound rules → Edit inbound rules. Add a rule: type MySQL/Aurora, source Custom, paste your DashboardFox IP with
/32on the end (e.g.,52.10.20.30/32). Repeat for every IP listed in DashboardFox's Firewall Allow List.Where to add it in Azure Database for MySQL
In the Azure portal, open your MySQL server → Networking → Firewall rules. Add a rule with the same start and end IP set to your DashboardFox IP. Don't forget to enable Allow public access if it's off.
Where to add it in DigitalOcean
Open your database cluster → Settings tab → Trusted sources. Click Edit, paste your DashboardFox IP, save.
Where to add it in another managed provider
Find a section called Network, Networking, Firewall, or Trusted sources in your provider's console.
- Google Cloud SQL: instance → Connections → Networking → Add a network.
- Heroku ClearDB / JawsDB: usually no firewall to configure — these add-ons are reachable from the internet by default.
- Aiven, PlanetScale, Vultr Managed: usually a Network or IP allow list section in the database settings.
Where to add it for self-hosted MySQL
This is whatever firewall your server runs:
- Linux
ufw:sudo ufw allow from <your-DBF-ip> to any port 3306. - Cloud provider firewalls (Vultr, Linode, Hetzner consoles all have a separate firewall layer): allow inbound TCP from your DashboardFox IP on port 3306.
- Windows Firewall: an inbound rule for TCP 3306, scoped to your DashboardFox IP.
-
Enter the details in DashboardFox and test
In DashboardFox, go to Settings → Integrations → Active Integrations → Create App → Database. Give it a name (e.g., "AWS MySQL"). Pick MySQL as the database driver.
Fill in the four values from step 1: host as the database server, your username, the database name, and the password. Click Test Connection.
If the test passes, click Save & Apply. The connection becomes a new app in DashboardFox — that's the term for a configured data source you build reports on.
If the test fails, DashboardFox shows you the exact error message AWS (or your provider) sent back. Common ones: "Access denied for user" means wrong password; "Unknown database" means wrong database name; a long timeout usually means firewall.
What if my MySQL uses a non-standard port?
DashboardFox uses port
3306automatically. If your provider uses a different port (DigitalOcean uses25060; some self-hosted setups use a custom port for security), open the Additional settings accordion below the form and addPort=NNNN;in the Additional connection string parameters field. ReplaceNNNNwith your actual port.You can also append it directly to the database server field with a semicolon, like
myserver.example.com;Port=25060. -
Grant access to your new app
Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.
Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.
Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.
-
Build your first app
You're connected and you have access. Now you shape the data model — pick which tables you want, name fields in plain English, define relationships. That's a separate lesson because it deserves its own walkthrough: Building your first app →.
Come back here if you ever need to update the connection itself (password changed, host moved, etc.).
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
The connection above works. Before you let your team or customers loose on it, two things are worth doing.
Use a read-only database user
The credentials you used in step 1 might be your admin login (in the video, that's the AWS RDS master user). DashboardFox only ever reads data, but it's still safer to use a dedicated user that can only read. The blast radius if those credentials ever leak is much smaller.
Show the SQL to create one
-- Run this in your MySQL console as a user with admin rights
CREATE USER 'dashboardfox_reader'@'%' IDENTIFIED BY 'pick-a-strong-one';
GRANT SELECT ON your_database.* TO 'dashboardfox_reader'@'%';
FLUSH PRIVILEGES;Then go back to Settings → Integrations, edit your app, and swap the user and password to the new one. The '%' means "from any host" — narrow it to your DashboardFox IP if you want extra security.
Restrict your firewall to DashboardFox's IP
If you allowed all IPs through your firewall in step 2 just to get going, narrow it down now. Only your DashboardFox IPs need through (you'll find them in Settings → Integrations → Firewall Allow List). Everything else stays blocked. Same place you added the IP in step 2 — just remove the wide-open rule.
Need stored procedures, direct SQL, or to adjust query timeouts? See Advanced data source settings.
If you're stuck
Most connection problems fall into one of these. DashboardFox passes the exact error message from MySQL back to you, so the wording will match.
I see "Access denied for user 'X'@'Y'"
The username or password is wrong. Reset the password in your provider's console, paste it fresh into DashboardFox (no extra spaces), and test again.
If the error mentions a specific host (the part after @), the user might exist but isn't allowed to connect from outside. Your DBA or hosting provider needs to grant the user permission for the right host (e.g., 'reader'@'%').
I see "Unknown database 'X'"
The database name field doesn't match a real database. Check the spelling — MySQL is case-sensitive on Linux servers (most cloud hosts) but not on Windows. If you connected with the same user via another tool (MySQL Workbench, etc.), the database name there is what to use here.
The test just times out (no specific error)
Almost always a firewall issue. Go back to step 2 and check that every IP from DashboardFox's Firewall Allow List is on your provider's allow list. On AWS RDS specifically, double-check that the security group is the one actually attached to your database, and that Public accessibility is set to Yes.
I see "Lost connection to MySQL server during query"
The connection got through but then dropped. Usually a network issue or a query timeout. If it happens during testing (not during real reports), check whether your provider has an idle timeout that's shorter than DashboardFox's connect-and-test sequence.
The connection saved fine, but I can't see the app in App Builder
You skipped step 4 (Grant access). Go to Settings → Security → Apps, find the app, click Edit, assign yourself App Builder, and save. This is the most common first-day surprise — you're not doing anything wrong.
None of these match my error
Email team@dashboardfox.com with a screenshot of the error and your provider name (e.g., "AWS RDS"). Copy the whole error message — the wording is usually enough for us to spot the issue. Same business day reply.
Background
This page walks you through connecting a Microsoft SQL Server that you (or your company) host — most commonly a SQL Server sitting on a server in your office, behind a corporate firewall. Self-hosted, AWS RDS for SQL Server, SQL Server on a cloud VM, or a small-office setup all follow this path.
If your SQL Server is hosted on Azure (Azure SQL Database), use the Azure SQL tab — Azure's setup is similar but has its own quirks.
Heads-up: SQL Server connections behind a corporate firewall usually need help from your DBA or whoever manages the server and firewall. There are three things they need to do before you can connect — we'll spell out what to ask for.
Stuck anywhere? Email team@dashboardfox.com. We'll help.
Before you start
- Your SQL Server connection details — host, port, database name, user, password. (You'll likely get these from your DBA — see step 1.)
- Three things your DBA needs to handle first: Mixed Mode authentication enabled, TCP/IP protocol enabled in SQL Server, and the firewall opened to DashboardFox's IP on the SQL port.
- About 10 minutes (longer if you have to wait on your DBA).
Do it
-
Get your connection details (and ask your DBA for the pre-flight)
Behind a corporate firewall, you don't get the connection details from a cloud console — you get them from your DBA, IT admin, or whoever manages the SQL Server. Before they can hand you anything, they need to handle three things on the SQL Server side.
Three things your DBA needs to set up:
- Mixed Mode authentication enabled. By default, SQL Server uses Windows authentication only. DashboardFox connects with a SQL login (username + password), so the server has to accept that mode. They'll switch this in SQL Server Management Studio under server properties.
- TCP/IP protocol enabled on the server. SQL Server can have TCP/IP turned off out of the box. They'll enable it in SQL Server Configuration Manager.
- The firewall opened to your DashboardFox IP on the SQL port (default
1433, often a non-standard port like11433for security — see step 2).
Once they've done those three, ask them for: the server address (IP or DNS name), the port, the database name, and a read-only SQL user ID and password.
Self-hosted on-prem behind corporate firewall (the video example)
Most likely scenario: your SQL Server lives on a server in your office or data center. Your DBA gives you a connection string after handling the three pre-flight items. Ports are often non-standard (e.g.,
11433instead of1433) for extra security — that's done via NAT on the firewall.Common extra needed:
TrustServerCertificate=true. We cover that in step 3.Using AWS RDS for SQL Server
RDS handles Mixed Mode auth and TCP/IP for you. Open the AWS console → RDS → click your SQL Server database. The Endpoint is your host. Database name (sometimes blank — leave it as the default), master username, port (default
1433) all live on the Configuration tab. Make sure Public accessibility is Yes.You won't need
TrustServerCertificate=truefor RDS — AWS uses real certificates.SQL Server on a cloud VM (AWS EC2, Azure VM, Google Compute Engine)
Same as on-prem from DashboardFox's perspective — you've installed SQL Server yourself on a VM. Your VM admin still needs to handle Mixed Mode auth, TCP/IP, and Windows Firewall on the VM. Plus the cloud provider's network rules (Security Groups on AWS, NSGs on Azure, firewall rules on GCP) need to allow the SQL port from DashboardFox's IP.
Small-office self-hosted (no DBA)
If you installed SQL Server yourself, you'll need to do the three pre-flight items. Microsoft's docs have walkthroughs for each. Or email us at team@dashboardfox.com — we'll walk you through it.
-
Verify your firewall lets DashboardFox in
Find your DashboardFox IP: in DashboardFox, go to Settings → Integrations → Firewall Allow List. Copy every IP listed (one or several depending on your region). Give them to whoever manages your firewall.
For self-hosted, this typically means giving DashboardFox's IP to your network admin so they can add an inbound rule on the corporate firewall — allowing TCP traffic from DashboardFox's IP to your SQL Server's port.
Self-hosted on-prem (corporate firewall)
Your network or firewall admin adds an inbound rule allowing TCP from DashboardFox's IP to the NAT'd public-facing port that maps to your SQL Server (often a non-standard port like
11433that maps to1433internally). They do this in your firewall appliance — every brand is different.AWS RDS for SQL Server
Open your database in the RDS console → Connectivity & security tab → click the VPC security group → Inbound rules → Edit inbound rules. Add a rule: type MS SQL, source Custom, paste your DashboardFox IP with
/32on the end.SQL Server on a cloud VM
Two layers to handle:
- The cloud network layer: AWS Security Group, Azure NSG, or GCP firewall rule allowing TCP from DashboardFox's IP on the SQL port.
- The VM's own firewall: Windows Firewall typically — an inbound rule for TCP
1433(or your custom port) from DashboardFox's IP.
Small-office Windows Firewall
On the SQL Server itself: Windows Defender Firewall → Advanced Settings → Inbound Rules → New Rule → Port → TCP
1433(or your custom port) → scope: Remote IP = your DashboardFox IP. -
Enter the details in DashboardFox and test
In DashboardFox, go to Settings → Integrations → Active Integrations → Create App → Database. Give it a name (e.g., "Internal Academy Database"). Pick Microsoft SQL as the database driver.
Important — port goes in the Server field with a comma. SQL Server is unique here. If your port is non-standard, format the database server like this:
myserver.example.com,11433Comma, no space. If your port is the default
1433, you can leave just the hostname.Fill in the rest: user, database name, password. Click Test Connection.
If the test fails with a "pre-login handshake error" or anything mentioning certificates, that's the most common gotcha for self-hosted SQL Server. See the next expander.
I see "pre-login handshake" or a certificate error
This is the SQL Server-specific gotcha. On self-hosted SQL Server (especially older versions or anything behind a corporate firewall), the server's TLS certificate is usually self-signed — and DashboardFox doesn't trust it by default. The fix:
Open the Additional settings accordion below the connection form. In the Additional connection string parameters field, paste:
TrustServerCertificate=trueTest again. The connection should pass.
You won't need this on AWS RDS for SQL Server (real certificates) or on cloud VMs running modern SQL Server with proper certificates configured.
My server uses a named instance
Some SQL Server setups use named instances like
MYSERVER\SQLEXPRESS. The format works in the database server field — just use a single backslash. If you also have a non-standard port, combine:MYSERVER\SQLEXPRESS,11433. -
Grant access to your new app
Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.
Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.
Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.
-
Build your first app
You're connected and you have access. Next step is shaping the data model: Building your first app →.
Come back here if you ever need to update the connection itself.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
The connection above works. Before you let your team or customers loose on it, two things are worth doing.
Use a read-only SQL Server user
If your DBA gave you a SQL login that's already read-only, you're set. If not — or if you used the admin sa login to get going — switching to read-only is a low-friction security win. Ask your DBA to run this, or run it yourself if you have admin access.
Show the T-SQL to create one
-- Run on your SQL Server in master, then in your database
USE [master];
CREATE LOGIN dashboardfox_reader WITH PASSWORD = 'pick-a-strong-one';
USE [your_database];
CREATE USER dashboardfox_reader FOR LOGIN dashboardfox_reader;
ALTER ROLE db_datareader ADD MEMBER dashboardfox_reader;Then go back to Settings → Integrations, edit your app, and swap the user and password to the new login.
Restrict your firewall to DashboardFox's IPs
If your firewall admin opened the SQL port to a wider range to get going, narrow it down now. Only DashboardFox's IPs (in Settings → Integrations → Firewall Allow List) should be allowed through. Same firewall rule from step 2 — just tighten the source.
Need stored procedures, direct SQL, or to adjust query timeouts? See Advanced data source settings.
If you're stuck
SQL Server's errors can be cryptic. DashboardFox passes them through unchanged — these are the common ones.
I see "A network-related or instance-specific error" / "Cannot connect to server"
Three possible causes:
- Firewall is blocking the connection — check your firewall rule from step 2 includes DashboardFox's IP and the right port.
- The server address is wrong — typo in the host, or you used the internal IP instead of the public one.
- TCP/IP protocol isn't enabled on SQL Server — ask your DBA to verify in SQL Server Configuration Manager.
I see "Login failed for user"
The credentials are wrong, OR Mixed Mode authentication isn't enabled on the server. If you're sure the password is right (and you've verified it works in SQL Server Management Studio), ask your DBA to confirm Mixed Mode is on.
I see "pre-login handshake" or a certificate / SSL error
This is the most common SQL Server gotcha. The server's certificate isn't trusted by DashboardFox — usually because it's self-signed (typical for self-hosted setups).
Open Additional settings on your connection, add TrustServerCertificate=true in the Additional connection string parameters field, and test again. See step 3 for details.
I see "Cannot open database"
The database name is wrong, or your user doesn't have access to it. Check the database name spelling. If correct, ask your DBA to verify your SQL login is mapped as a user in that specific database with at least db_datareader permissions.
The test just times out
Firewall is silently dropping the connection (no "refused" message means the firewall isn't even sending a rejection back). Have your firewall admin verify the inbound rule allows TCP from DashboardFox's IP to the SQL port — and that the rule is on the right firewall (corporate edge, server-local Windows Firewall, or both).
The connection saved fine, but I can't see the app in App Builder
You skipped step 4 (Grant access). Go to Settings → Security → Apps, edit the app, assign yourself App Builder, save.
None of these match my error
Email team@dashboardfox.com with a screenshot of the error message. SQL Server errors are wordy but specific — the exact text is usually enough for us to pin down the cause.
Background
This page walks you through connecting an Azure-hosted SQL Server to DashboardFox — Azure SQL Database (the managed cloud service, by far the most common), Azure SQL Managed Instance, or SQL Server running on an Azure VM. The video uses Azure SQL Database as the example.
Azure SQL is Microsoft's managed cloud SQL Server. Most of what you'd do for self-hosted SQL Server is handled for you — Mixed Mode auth and TCP/IP are already on. The differences are the firewall pattern (Azure-specific) and a few extra connection string parameters Azure requires.
If your SQL Server is on-prem or self-hosted, use the SQL Server tab instead.
Stuck anywhere? Email team@dashboardfox.com. We'll help.
Before you start
- Your Azure SQL connection details — host, database name, admin username, password. (We'll show you where to find these in step 1.)
- Admin or Contributor permission on the Azure SQL server (or someone with it who can add a firewall rule for you).
- About 5 minutes.
Do it
-
Find your connection details in Azure
You need: host (the server address), database name, user, password, and a few extra connection string parameters Azure requires.
Using Azure SQL Database (the video example)
In the Azure portal, open the database you want to connect to. Click Connection strings in the left menu and pick the ODBC tab — that gives the cleanest, easiest-to-read format.
You'll see a string like this:
Driver={...};Server=tcp:myserver.database.windows.net,1433;Database=mydb;Uid=admin;Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;From it, pull out:
- Host: the part starting with
tcp:through the port, but without the trailing semicolon — copytcp:myserver.database.windows.net,1433straight into the database server field. - Database: the value after
Database=. - User: the value after
Uid=(your admin login or a SQL user you've created). - Password: the password for that user (Azure doesn't show it — you set it when the server was created, or use the latest reset value).
- Extras for Additional settings:
Encrypt=yes(Azure requires this),Connection Timeout=30. We'll add these in step 3.
Using Azure SQL Managed Instance
Same flow as Azure SQL Database. The server name format differs — looks like
myinstance.public.<identifier>.database.windows.netfor public-endpoint instances. If your Managed Instance only has a private endpoint, you'll need a VPN or ExpressRoute to reach it; talk to your Azure admin.SQL Server on an Azure VM
That's actually a self-hosted SQL Server scenario, not Azure SQL. Use the SQL Server tab instead — the setup follows the on-prem path (Mixed Mode auth, TCP/IP, Windows Firewall, etc.).
- Host: the part starting with
-
Allow DashboardFox in Azure's firewall
Azure's firewall is at the SQL server level, not the database level. One firewall rule covers every database on that server, so you only do this once even if you have multiple databases.
Find your DashboardFox IP: in DashboardFox, go to Settings → Integrations → Firewall Allow List. Copy every IP listed.
Adding the firewall rule in Azure
In the Azure portal, open your database → in the breadcrumbs, click the parent SQL server (not the database). Then:
- Click Networking in the left menu.
- Under Public network access, choose Selected networks (if it's currently Disable, you'll switch it).
- Under Firewall rules, click Add a firewall rule.
- Give it a name (e.g., "DashboardFox"), and set the Start IP and End IP both to your DashboardFox IP.
- Save.
Repeat for every IP listed in DashboardFox's Firewall Allow List.
What about "Allow Azure services and resources to access this server"?
That toggle on the Networking page is unrelated to DashboardFox — it controls whether other Azure services (like an Azure Function or another Azure database) can connect. Leave it however your Azure admin has it. DashboardFox connects from outside Azure, so it relies on the explicit IP rule you just added.
-
Enter the details in DashboardFox and test
In DashboardFox, go to Settings → Integrations → Active Integrations → Create App → Database. Give it a name (e.g., "My Azure SQL"). Pick Microsoft SQL as the database driver (Azure SQL uses the same driver as on-prem SQL Server).
Fill in the four basics: host, user, database, password.
Then add the extra connection string parameters Azure requires. Open the Additional settings accordion below the form. In the Additional connection string parameters field, paste the extras from the Azure connection string — separated by semicolons:
Encrypt=yes;Connection Timeout=30;Click Test Connection. If it passes, click Save & Apply.
If the test fails, DashboardFox shows you Azure's exact error message. Common: "Login failed for that particular user" means wrong password.
What about Azure AD authentication?
Azure SQL supports Azure AD (now Microsoft Entra ID) authentication in addition to SQL authentication. The video covers SQL auth, which is the simpler path. If your Azure admin requires Azure AD auth, the connection string format changes — there's an additional parameter
Authentication=ActiveDirectoryPassword(or similar) that goes in Additional settings. Email team@dashboardfox.com if you need help with this — it varies by Azure tenant configuration. -
Grant access to your new app
Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.
Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.
Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.
-
Build your first app
You're connected and you have access. Next step is shaping the data model: Building your first app →.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
The connection above works. Before you let your team or customers loose on it, two things are worth doing.
Use a read-only SQL user
The user you connected with is probably the Azure SQL admin login. DashboardFox only reads, but switching to a dedicated read-only user is a low-friction security win.
Show the T-SQL to create one
-- Run on your Azure SQL Database
-- Connect as the admin user, against your specific database
CREATE USER dashboardfox_reader WITH PASSWORD = 'pick-a-strong-one';
ALTER ROLE db_datareader ADD MEMBER dashboardfox_reader;Then go back to Settings → Integrations, edit your app, and swap the user and password. Note: Azure SQL Database uses contained users (created directly in the database with a password), not server-level logins. The SQL above creates exactly that.
Restrict the Azure firewall rule to DashboardFox's IPs only
If you (or someone) ever opened the Azure firewall to a broader range to get going, narrow it now. Each rule should be just one DashboardFox IP (Start IP = End IP). Same Networking page from step 2 — edit or delete any wide-open rules.
Need stored procedures, direct SQL, or to adjust query timeouts? See Advanced data source settings.
If you're stuck
Azure passes specific error messages back, which DashboardFox shows you unchanged. These are the most common ones.
I see "Login failed for user 'X'"
The username or password is wrong. Reset the admin password in the Azure portal (under your SQL server → Reset password), or have your admin reset the user's password. Paste it fresh into DashboardFox and test again.
I see "Cannot connect to server" or a long timeout
The Azure firewall isn't allowing your DashboardFox IP. Go back to step 2: open your SQL server (the parent, not the database) → Networking → Firewall rules → confirm there's an entry with both Start IP and End IP set to your DashboardFox IP.
Also confirm Public network access is set to Selected networks, not Disable.
I see something about encryption or "does not support encryption"
You're missing the Encrypt=yes parameter Azure requires. Open Additional settings on your connection, add Encrypt=yes in the Additional connection string parameters field, and test again.
I see "Cannot open database"
The database name is wrong, OR your user doesn't have access to that specific database. Check the database name spelling exactly. If you used the admin login, you should have access; if you used a contained user, that user only has access to the database where it was created.
The connection saved fine, but I can't see the app in App Builder
You skipped step 4 (Grant access). Go to Settings → Security → Apps, edit the app, assign yourself App Builder, save.
None of these match my error
Email team@dashboardfox.com with a screenshot. Azure error messages are usually specific enough for us to spot the issue quickly.
Background
This page walks you through connecting an Oracle database to DashboardFox. Oracle uses some terminology that's a little different from MySQL or SQL Server — we'll explain as we go.
Most Oracle setups are managed by a DBA who can give you everything you need. If you're connecting to AWS RDS for Oracle, the pattern is similar to RDS for MySQL or Postgres — your hosting console gives you the connection details directly.
Stuck anywhere? Email team@dashboardfox.com. We'll help.
Before you start
- Your Oracle connection details — host, port, the SID or Service Name, user, password. (See step 1 — these terms are Oracle-specific and we'll explain.)
- If you're connecting to a corporate Oracle database, the same DBA pre-flight as SQL Server applies — Oracle needs to be configured for remote connections, and a firewall rule needs to allow DashboardFox's IP.
- About 10 minutes.
Do it
-
Find your connection details (and understand SID vs Service Name)
Oracle databases are identified one of two ways: by SID (an older "system identifier" name) or by Service Name (the newer way, what most modern setups use). DashboardFox accepts either — you put whichever your DBA gives you in the database name field.
What you need: host, port (default
1521), SID or Service Name, user, password. Oracle is case-sensitive on usernames and passwords — match exactly how the user was created.Using AWS RDS for Oracle
Open the AWS console → RDS → click your Oracle database. The Endpoint is your host. The port (default
1521) and the DB Name are on the Configuration tab — the DB Name in RDS is your SID. Master username and password are also there. Make sure Public accessibility is Yes if you're connecting from outside AWS.Self-hosted Oracle (corporate or on-prem)
Same pre-flight conversation as SQL Server: ask your DBA to confirm the Oracle listener is configured for remote connections, the firewall is open to DashboardFox's IP on port
1521(or whatever you use), and that they create a read-only Oracle user for you.Ask them whether to use SID or Service Name — they'll tell you which one their setup uses.
Oracle Cloud Infrastructure (OCI) Database
OCI gives you a connection string when you provision a database. From it, extract host, port, and Service Name. The console's Database Connection page shows everything you need.
-
Allow DashboardFox through your firewall
Find your DashboardFox IP: in DashboardFox, go to Settings → Integrations → Firewall Allow List. Copy every IP listed.
AWS RDS for Oracle
Open your database in the RDS console → Connectivity & security tab → click the VPC security group → Inbound rules → Edit inbound rules. Add a rule: type Oracle-RDS (or Custom TCP on port 1521), source Custom, paste your DashboardFox IP with
/32.Self-hosted on-prem
Work with your firewall admin to allow inbound TCP from DashboardFox's IP to your Oracle listener port (default
1521, or whatever your DBA uses).Self-hosted on a VPS or VM
Two layers, like SQL Server: the cloud network firewall (e.g., AWS Security Group, Vultr/Linode firewall) and the OS firewall (Linux
ufworfirewalld). Both need to allow TCP from DashboardFox's IP to port 1521. -
Enter the details in DashboardFox and test
In DashboardFox, go to Settings → Integrations → Active Integrations → Create App → Database. Give it a name. Pick Oracle as the database driver.
Fill in the values: host as the database server, your username (case-sensitive), the SID or Service Name as the database, and the password. Click Test Connection.
Non-standard port?
DashboardFox uses port
1521automatically. If your Oracle listener is on a different port, open Additional settings and addPort=NNNN;in the Additional connection string parameters field.Service Name vs SID — which goes in the database field?
Whichever your DBA gave you. DashboardFox tries to figure out which one you've supplied based on the connection. If the test fails with an Oracle error mentioning the listener (like ORA-12514 or ORA-12505), you may have the wrong type — ask your DBA whether to use SID or Service Name and try the other one.
-
Grant access to your new app
Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.
Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.
Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.
-
Build your first app
You're connected and you have access. Next step: Building your first app →.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
The connection above works. Before you let your team or customers loose on it, two things are worth doing.
Use a read-only Oracle user
If your DBA gave you a read-only user, you're set. If not, ask them — or run the SQL below if you have admin (DBA) access.
Show the SQL to create one
-- Run as a DBA-privileged user
CREATE USER dashboardfox_reader IDENTIFIED BY "pick-a-strong-one";
GRANT CREATE SESSION TO dashboardfox_reader;
-- Then for each table you want to expose:
GRANT SELECT ON your_schema.your_table TO dashboardfox_reader;
-- Or grant SELECT on every existing table in a schema:
-- (Run this query to generate the GRANT statements)
SELECT 'GRANT SELECT ON your_schema.' || table_name
|| ' TO dashboardfox_reader;'
FROM all_tables
WHERE owner = 'YOUR_SCHEMA';Oracle doesn't have a single "give SELECT on everything" command at the schema level for users (unlike Postgres or MySQL) — your DBA either grants per-table or sets up a role. Then go back to Settings → Integrations and swap the user.
Restrict your firewall to DashboardFox's IPs
Same pattern as the other tabs: narrow your firewall rule to only DashboardFox's IPs. Same firewall as step 2 — just tighten the source IPs.
Need stored procedures or direct SQL? See Advanced data source settings.
If you're stuck
Oracle errors all start with "ORA-" and a number. DashboardFox passes them through unchanged.
I see "ORA-12154: TNS:could not resolve the connect identifier"
Oracle can't make sense of your host or service name. Check the host address for typos. If your DBA uses a service name in the format myservice.example.com, that's the host part — not the database part. Verify each value.
I see "ORA-01017: invalid username/password"
The credentials are wrong. Oracle is case-sensitive — match the username and password exactly as your DBA gave them. Reset the password and paste it fresh.
I see "ORA-12541: TNS:no listener"
Either the Oracle listener isn't running, or the firewall is blocking the connection on the listener port. If your DBA confirms the listener is running, this is a firewall issue — go back to step 2.
I see "ORA-12505" or "ORA-12514: TNS:listener does not currently know of service"
Usually means SID vs Service Name confusion. The listener is running and reachable, but doesn't recognize what you put in the database field. If you tried it as a Service Name, ask your DBA if it's actually a SID (or vice versa) and try the other one.
The connection saved fine, but I can't see the app in App Builder
You skipped step 4 (Grant access). Go to Settings → Security → Apps, edit the app, assign yourself App Builder, save.
None of these match my error
Email team@dashboardfox.com with the full ORA error code and message. Oracle errors are very specific — the code alone usually tells us the cause.
