Package Console as an installer

[graikhel-intel]

Description

Console is currently distributed as a standalone binary. We want to improve the installation and deployment experience by providing an installer-based distribution for Windows and Ubuntu.

The initial goal is to support:

• Windows installer
• Ubuntu package (.deb)

Based on customer feedback, support for additional Linux distributions can be evaluated later.

This should provide a more complete installation experience and support common lifecycle operations such as:

• Install
• Uninstall
• Upgrade to a newer version

This also gives us an opportunity to improve the initial setup experience, such as making the initial username and password configurable during installation.

For Windows, one possible direction is to have Console run through the system tray / app tray experience. For Ubuntu, the initial packaging direction would be a Debian package.

Open Questions

• Should Console run as a service, a system tray application, or support both modes? What are the pros and cons of a service-based install vs a system tray based install, especially for Windows? A system tray based experience may be better suited for Console.
• For Ubuntu, should the primary installation model be a .deb package that installs Console and configures it to run as a systemd service? Another option is a Snap package.
• How should initial setup and configuration be handled during installation?
• How should customers configure external authentication such as OAuth2 / OIDC if they want to use it?
• How should installer-based setup handle custom database configurations, such as customers using their own PostgreSQL instance instead of the default SQLite?
• Where should Console store binaries, configuration, logs, and persistent data on Windows and Ubuntu?
• How should upgrades preserve existing config, credentials, database files, logs, and user-provided settings?
• How should third-party OSS license notices and attribution files be packaged and made accessible as part of the installer?
• What should uninstall remove vs preserve (application files, config, logs, database, etc.)?
• If installer-based distribution introduces additional release, packaging, or process approval requirements, should this work first ship through a separate branch (for example next) before merging into main?
• On Windows, what installer-specific registry entries are actually needed, and which configuration should remain file-based instead of registry-based?
• Can Console be installed with elevated privileges if required, but run day-to-day without requiring admin/root access?
• If Console runs as a service, what is the lowest-privilege service account model we should support?
• Where should config, logs, and persistent data be stored so Console can operate correctly without requiring admin/root privileges after install?

Acceptance Criteria

• Define the installer-based distribution approach for Windows and Ubuntu.
• Define how install, uninstall, and upgrade flows should work.
• Define how initial setup and configuration should be handled.
• Define how installer-based deployments handle custom authentication and database configurations.
• Identify follow-up implementation work for packaging and installer support.