On-Premise AI Database Chatbot Deployment

AskYourDatabase offers an Enterprise deployment for running its database chatbot application on your own infrastructure. Hosting the application privately does not automatically keep AI processing inside your network. Choose where the language model runs, then verify the complete data path before connecting sensitive databases.

This guide helps an IT or data team evaluate private deployment for conversational database reporting. It covers deployment choices, information sent to a model, infrastructure planning, acceptance checks, and the questions needed for an Enterprise quote. For individual analysis with a local database connection, compare the Desktop workflow; Desktop is not an offline model server.

Content reviewed November 4, 2026. The checks below are an evaluation plan, not a claim that your environment has passed a security assessment.

Choose the application and model locations separately

The private application with external AI is appropriate when you need to control application hosting and database connectivity but can approve model-provider processing. It still needs network access for inference, in addition to any license or operational dependencies.

For a self-hosted model, agree the supported model, endpoint, and feature set with the Enterprise team. Do not assume that every OpenAI-compatible endpoint supports every tool call, chart, or analysis workflow. A model name or a private server address is not evidence of a fully isolated deployment.

If your policy requires an air-gapped system, make that a requirement at evaluation time. Confirm licensing, authentication, model routing, updates, and analysis services under that restriction before procurement. This guide does not promise a turnkey air-gapped package.

Build a dependency map before calling a deployment private

An on-premise AI chatbot for SQL reporting has more than one network boundary. Fill in the following map for the exact release and workflows being evaluated. These are review categories, not a list of services that every AskYourDatabase deployment necessarily uses.

Do not put credentials or private endpoints into a public checklist. Use protected references to configuration and evidence. An unknown dependency remains an open item; checking only the first successful SQL answer will miss paths used later in a conversation.

For example, the standard email sign-in configuration described below still needs its delivery path to work. Reusing an existing browser session does not test that dependency. Likewise, downloading an update and serving an already installed application are different network operations. Agree how both will work before accepting a restricted-network design.

Download the private deployment evaluation worksheet to record these decisions. It is an editable planning document, not a deployment script, product configuration file or certification. The fields for observed results are deliberately blank.

Worked example: local SQL, external inference

Consider a fictional finance team that permits an aggregate invoice total to reach an approved model provider, but prohibits customer names and invoice descriptions from leaving its network. This example illustrates a decision process; it is not a customer deployment or an executed product test.

1. The database owner prepares an approved reporting view containing company code, currency and unpaid totals, with no customer names or free-text descriptions. The reporting account can access that view, not the underlying detail tables.
2. The team records that application hosting and SQL execution are private, while model inference is external. It reviews the schema, prompt, result and conversation data that the entire workflow can send. A view with fewer columns helps limit available data, but the prompt itself could still contain a name.
3. In staging, the evaluator asks for totals, follows up with a narrower date range and requests an invoice detail that the view does not expose. They check the executed queries, model-request categories and retained history, not just the visible answer.
4. If the required detail cannot be answered within the approved scope, the outcome is an explicit limitation or a revised, reviewed design. Adding a training instruction to hide names does not create an enforced data boundary.

Now change the requirement to no external inference. The same private application plus external model no longer meets it. The team must evaluate an agreed self-hosted model and the complete dependency map, including email, licensing, updates and optional analysis. Neither changing the database host nor hiding SQL in the interface establishes that requirement.

Use the text-to-SQL evaluation guide for checked answers and the audit evidence guide for connecting questions to execution records. Accuracy, permitted data flow and operational readiness need separate evidence.

What information can reach the AI model?

The database connection and the model request are separate operations. A typical reporting conversation can involve:

1. Question and context: the user's request, conversation history, schema names, table or column descriptions, and training examples help the model decide what to query.
2. Database query: the application executes a generated query using the configured database account and permitted data sources.
3. Follow-up analysis: selected query output or tool results can be included in later model messages to explain results or produce the next step.
4. Application records: conversation and tool-result content may be retained in application storage. Logs, backups, exports, and analysis outputs also need an explicit retention plan.

With an external model API, data included in those model messages leaves the application environment. Keeping the source database in your network is not the same as preventing row values from leaving it. Reducing or truncating a result is not anonymization.

For example, a question about unpaid invoices might expose customer names if they are present in the permitted view and returned result. A reporting view with only approved columns can reduce the available data before a model request is made. Training examples help explain business rules; they do not replace database permissions.

Read the security and data-flow guide for the Desktop and hosted Chatbot boundaries. Agree the actual processor list, retention, and deployment configuration for your organization rather than assuming one product's behavior applies to another.

Infrastructure and cost planning

The existing application deployment guidance uses Docker, persistent storage, and a starting server specification of 4 CPU cores, 8 GB RAM, and 80 GB storage. Treat this as an application starting point to validate under your expected load, not a performance guarantee or a specification for running a large language model.

Plan these separately:

• Application and state: application containers, persistent database storage, backups, certificates, and monitoring.
• Database connectivity: approved network routes, credentials with limited privileges, connection limits, query timeouts, and database-side encryption requirements.
• External inference: provider accounts, model access, API usage cost, rate limits, and permitted request destinations.
• Self-hosted inference: model weights and license, serving software, CPU/GPU memory, context length, concurrency, and an operator responsible for upgrades. Size this against the chosen model and workload.
• Optional workflows: confirm dependencies for Python analysis, dashboard operations, embedding, authentication, and integrations you intend to use.

A container starting successfully does not establish production readiness. Docker's production guidance (opens in a new tab) also distinguishes production configuration, restart behavior, and operational changes from local development.

Enterprise pricing is quoted for the agreed deployment and user scope. Model usage or model-hosting hardware, infrastructure operations, and support requirements belong in the total cost. Use the plan comparison to compare product paths, then request an Enterprise evaluation with your requirements. Do not assume cloud plan quotas or feature coverage transfer unchanged to a private contract.

A practical deployment evaluation

1. Define one reporting workflow

Start with a question such as “Show unpaid invoice totals by company as of the month end.” Specify authorized companies, reporting dates, currencies, and expected totals. Use synthetic or approved test data before connecting production data. The ERP reporting guide provides a worked reconciliation example; the natural-language query guide explains general answer validation.

2. Agree the release and dependency map

Obtain the supported deployment package and version-specific configuration from the Enterprise team. Record where the application, state database, model endpoints, backups, authentication, license checks, and optional analysis services run. Identify an owner for every dependency and document the outbound destinations that the approved workflow needs.

3. Prepare a limited database account

For reporting, use a read-only account limited to approved schemas, tables, or views. A firewall rule governs network reachability; it does not limit which records an authenticated database account can read. Combine database permissions with Chatbot access controls. Keep a credential out of prompts, screenshots, and training examples.

Follow the connection guide for the relevant engine. Confirm encryption and certificate validation for the specific connector and release. A successful connection alone does not prove either property. If a required transport policy cannot be demonstrated, resolve that before approving sensitive data access.

4. Test the full conversation and denial paths

Run the known-answer question, a follow-up, a request for another tenant's data, and an attempted write in a controlled test environment. Review the executed query, allowed result, retained history, and model destinations. For a customer-facing interface, also test the real authenticated user/session path described in the embedded chatbot guide.

5. Rehearse operations before rollout

Record the version and configuration that passed. Restore a backup into a test environment, rotate test credentials, exercise an unavailable model endpoint, and verify upgrade/rollback ownership. Load-test representative question and result sizes; do not estimate capacity from a single successful prompt. Approve the exact deployment after the acceptance evidence is available.

Configure email sign-in credentials

The standard private image includes the managed email sign-in configuration. To use your own Resend sending credential instead, optionally set AUTH_RESEND_KEY in the existing deployment's .env file. This is a server-only email credential, not an AI API key or a license key. It takes priority over RESEND_API_KEY and the built-in configuration. An optional AUTH_EMAIL_FROM sets the sender; otherwise the sender remains no-reply@askyourdatabase.com. A custom sender's domain must be verified in the same Resend account and allowed by the key.

Obtain the approved credential through your secure administration channel. Do not put it in a Docker image, Git repository, screenshot, or support email. Preserve all other settings, particularly AUTH_SECRET and DATABASE_URL. After configuring it, rerun the same supported one-line updater:

sudo curl -fsSL https://www.askyourdatabase.com/deploy-askyourdatabase.sh | bash

The updater preserves the existing .env and recreates only the application container. Existing installations using managed email do not need to add a new setting. Verify both requesting a fresh sign-in email and opening that email's link on your own application origin; an existing logged-in session alone does not test email delivery.

Acceptance checks to record

These are proposed tests for your team, not results from a completed AskYourDatabase benchmark.

Least-privilege access limits the consequences of model mistakes or hostile prompts. OWASP's prompt-injection guidance (opens in a new tab) recommends enforcing privileges in the surrounding system. An instruction to the model is not an authorization boundary.

For a worked business-readiness example, use the natural language query rollout guide. Its editable worksheet connects deployment decisions with metric ownership, a checked invoice reference and pilot sign-off.

What to bring to an Enterprise evaluation

Share the database types, approximate user count and concurrency, required workflows, permitted model providers, desired hosting region, and network restrictions. Describe which data categories may reach inference or logs and who will operate the deployment. Use a synthetic schema or a redacted example; do not send production credentials.

Attach the completed evaluation worksheet, with protected references rather than secrets, to your internal review. Resolve unknown dependencies and identify who will supply each missing piece of evidence.

Then contact the Enterprise team to agree a supported configuration, evaluation scope, and quote. If your requirement is primarily individual desktop analysis, start with the download and setup guide and review its external-inference boundary first.

Frequently asked questions