Skip to main content
PawSQL Server provides SQL analysis and governance inside an organization-controlled environment. This page defines the stable deployment lifecycle. Package names, commands, ports, and component versions must come from the release-specific delivery bundle.
Use installation media and deployment instructions that match the exact PawSQL Server version. Do not reuse commands from another release without verification.

​
Goal

Plan, deploy, initialize, and validate a private PawSQL Server environment.

​
Prerequisites

  • Installation media and deployment instructions that match the exact PawSQL Server version.
  • A separate, non-production environment to validate the release and rollback process before production.

​
Plan the environment

Production should not double as an installation test environment. Validate the release and rollback process in a separate environment first.

​
Deployment workflow

1

Verify the delivery bundle

Confirm the version, integrity information, release notes, deployment guide, and license.
2

Prepare infrastructure

Provision the required hosts, dependencies, service accounts, storage, DNS, and network policies.
3

Configure the service

Set endpoints, persistence, logging, authentication, and notifications. Store sensitive values securely.
4

Install and start PawSQL

Use the release-provided script or deployment template and record all local changes.
5

Initialize the platform

Create the initial administrator, apply the license, and establish organization-level settings.
6

Complete acceptance testing

Validate sign-in, permissions, task processing, persistence, logs, notifications, and database connectivity.

​
Network paths to validate

​
Security baseline

  • Run services under dedicated system identities.
  • Grant platform and database accounts only the permissions they need.
  • Use HTTPS and establish certificate rotation.
  • Restrict administrative endpoints by network and role.
  • Keep secrets out of repositories, ordinary scripts, and logs.
  • Protect backups and diagnostic data with explicit retention policies.
  • Require review, backup, validation, and rollback for production changes.

​
Acceptance checklist

  • All required services are healthy.
  • The expected URL is reachable.
  • TLS is trusted and the hostname matches.
  • Administrator and standard-user permissions behave correctly.
  • The license is valid.
  • A workspace and test task can be created.
  • Data persists across a controlled restart.
  • Monitoring, logging, and notifications are operational.
  • Backup and restore have been tested.
  • Version, configuration, ownership, and rollback details are recorded.
Do not upgrade production without a verified backup and rollback plan. Validate the release with sanitized SQL and non-production databases first.

​
Next steps

Verify the installation

Authentication

Workspaces