Deployment

This page provides an overview of all deployment modes available for Kitto^x applications. For development setup, see Web Server Configuration.

Application directory

When deploying a Kitto^x application, you need to provide its Application Home directory with the executable file and the Metadata and Resources subdirectories.

During development, the Application Home and System Home directories are separated. In deployment, it is recommended that you merge them together, keeping the Application Home files in case of duplicates. Use an installer tool like InnoSetup to automate this.

MyApp/
  Home/
    Metadata/
      Config.yaml         # Database, auth, server port, theme
      Models/              # Data model YAML files
      Views/               # UI definition YAML files
      Layouts/             # Panel layout YAML files
    Resources/             # Static files: CSS, JS, icons, images
      icons/               # SVG icons (filled/, outlined/, round/, sharp/, two-tone/)
    ReportTemplates/       # Excel/PDF report templates (optional)
  MyApp.exe                # Standalone / Service / Console executable
  # or MyAppISAPI.dll      # ISAPI DLL for IIS
  # or mod_myapp.dll       # Apache module

Choosing a deployment mode

Mode	Executable	HTTP Server	Best for	Guide
Standalone (GUI)	.exe	Indy (embedded)	Development, small deployments	Standalone
Windows Service	.exe (same binary)	Indy (embedded)	Production on Windows	Windows Service
Service + Proxy	.exe + nginx/Apache/IIS	Indy + reverse proxy	Production with HTTPS, multiple apps	Windows Service, Proxy
Console	.exe (separate .dpr)	Indy (embedded)	Docker, headless servers	Console
IIS (ISAPI DLL)	.dll	IIS via WebBroker	Enterprise Windows hosting	ISAPI (IIS)
Apache module	.dll / .so	Apache via WebBroker	Linux / cross-platform	Apache
Desktop Embedded	.exe	Indy + WebView2	Desktop app look & feel	Desktop Embedded

All modes use the same YAML metadata, the same controllers, and the same TKWebEngine core. The choice only affects how the HTTP server is hosted and managed.

Service + Proxy vs native modules

For production deployments, you can choose between:

• Service + Proxy: the application runs as a Windows Service with its own Indy HTTP server; a reverse proxy (nginx, Apache, or IIS ARR) forwards requests. Each app can be restarted independently without affecting the web server or other apps.
• Native modules (ISAPI/Apache): the application runs as a DLL loaded directly by the web server. Simpler setup (no proxy) but requires a full web server restart to update the DLL or reload YAML metadata.

See Windows Service Deployment for the proxy approach and Proxy Configuration for nginx/Apache/IIS setup details.

Common configuration

Regardless of deployment mode, every Kitto^x application uses Config.yaml for:

• Database connection (see Database Configuration)
• Authentication and access control (see Authentication)
• Session timeout and cleanup
• Theme, charset, localization

Session configuration applies to all modes:

Engine:
  Session:
    TimeOut: 30          # Session timeout in minutes
    CleanupInterval: 5   # Cleanup thread interval in seconds

Application tools

If your application uses one of the following tools, install the required software on the server:

Tool	Requirement
ADOTool (Excel export)	ADO/OLEDB provider
FlexCel (Excel export)	FlexCel commercial license (TMS)
ReportBuilder	ReportBuilder commercial license (Digital Metaphors)
PDFMerge	Debenu Quick PDF Library
FOPTool	Apache FOP 1.1

See also

• Web Server Configuration — development setup, .dpr examples, WebBroker bridge
• Proxy Configuration — reverse proxy with Apache/nginx
• Desktop Embedded Mode — WebView2 desktop application