Bolt.new can build the application, but it cannot reach a SQL Server sitting inside your network — and the usual workarounds are opening a firewall port or pasting the database password into the project. This build does neither. DreamFactory sits in front of the database, generates a REST API, and restricts it to a read-only role and a scoped API key; Bolt then calls that API from a Bolt server function to produce a live delivery operations dashboard.
What you’ll learn
- Why Bolt.new cannot open a direct connection to an on-prem SQL Server
- Generating a REST API over that database and scoping it read-only
- Calling the API from a Bolt server function instead of the browser
- Building a delivery operations dashboard against live on-prem data
Frequently asked questions
Can Bolt.new connect to an on-premise database?
Not directly — a Bolt project cannot open a database connection into a private network. It can call an HTTPS API, so the working pattern is to put a REST API in front of the database and have Bolt call that. In this video DreamFactory generates that API and Bolt consumes it from a server function.
Do I have to open a firewall port for Bolt.new to reach SQL Server?
No. The database stays closed to inbound traffic. DreamFactory is what holds the database connection, and Bolt only ever talks to the REST API over HTTPS with an API key, so no port is opened on the SQL Server itself.
Does Bolt.new ever see my SQL Server password?
No. The database credential is held by DreamFactory and never leaves it. Bolt receives only a scoped API key bound to a read-only role, so the most that key can do is read the tables that role permits.
