A local desktop launcher for phpMyAdmin connections, with saved database profiles and optional SSH tunnels for remote MySQL/MariaDB hosts.

The intended workflow is deliberately simple:

1. Keep phpMyAdmin and its runtime on your workstation.
2. Save the database environments you work with.
3. For a private database, describe an SSH bastion rather than opening MySQL to the internet.
4. Launch a dedicated local phpMyAdmin session for that environment.

The launcher, per-connection process routing, runtime installation/cache, local FrankenPHP serving, strict SSH tunnel lifecycle, and dedicated phpMyAdmin session flow are implemented on Windows. The runtime is still pre-release: Windows GUI/runtime end-to-end validation remains required, and connection credentials are currently persisted locally in servers.json rather than an OS credential store. Do not use production secrets until secure storage is added and the Windows acceptance checks have passed.

phpMyAdmin is useful, but its usual deployment model creates friction for people who manage several remote databases:

• each host may have a different database endpoint and credential set;
• the database should not need a public port;
• SSH port-forwarding is safer but repetitive to configure manually;
• a browser tab does not give a clean boundary between unrelated client/staging/production environments.

phpMyAdmin Desktop is meant to be the small local control plane around that workflow. It is not trying to replace phpMyAdmin, MySQL, or SSH. It should make the safe path—local phpMyAdmin plus a per-connection tunnel—the convenient path.

For local development, phpMyAdmin connects to MySQL/MariaDB directly:

phpMyAdmin Desktop → local phpMyAdmin → 127.0.0.1:3306

For a remote environment, the desktop app should create a local-only forward and point phpMyAdmin at it:

phpMyAdmin Desktop → local phpMyAdmin → 127.0.0.1:<ephemeral-port>
                                              │
                                              └─ SSH bastion → database-host:3306

The tunnel must bind to loopback only, use a free local port, propagate errors clearly, and shut down with its phpMyAdmin session. The database server remains private; the workstation is the only machine that talks to the tunnel.

• Go 1.25+ and Wails v3 alpha
• SolidJS, TypeScript, Vite
• Kobalte + solid-styled-components
• golang.org/x/crypto/ssh plus github.com/skeema/knownhosts for strict SSH forwarding
• github.com/AndreiTelteu/wails-configstore for the current local configuration store

Wails v3 is still pre-release software. The project intentionally pins the tested alpha version in go.mod.

The planned Windows runtime is the official FrankenPHP Windows archive, used in classic mode only. No worker directive is used: each phpMyAdmin request runs with the normal request lifecycle, which is the safe compatibility choice for an application that was designed around PHP's per-request state.

This means the runtime manager will download and checksum-pin a release archive, unpack it inside the app data directory, generate a minimal php.ini that enables phpMyAdmin's required extensions, and start frankenphp.exe with a generated Caddyfile containing php_server. It must retain and terminate that process as part of the selected connection session.

Do not compile FrankenPHP on an end-user machine. The upstream project publishes a Windows x86_64 archive containing frankenphp.exe, the compatible PHP runtime, and its required DLLs. This repository's Windows CI downloads the latest official archive and smoke-tests classic-mode PHP serving; the desktop app build is separately compiled on windows-latest.

RoadRunner has official Windows binaries, but it requires an application PHP worker process plus its worker protocol. That lifecycle is unnecessary for phpMyAdmin and does not eliminate bundling PHP/extensions. It is not the chosen runtime for this product.

• Go 1.25+
• Node.js + npm
• Wails v3 CLI matching go.mod
• Native Wails build dependencies for the OS you are building on

Linux builds require pkg-config, GTK development headers, and WebKitGTK development headers. Install the packages appropriate to your distribution before running Go/Wails builds. Windows and macOS need their standard Wails platform prerequisites.

Install the pinned CLI locally:

CGO_ENABLED=0 GOBIN="$HOME/.local/bin" go install github.com/wailsapp/wails/v3/cmd/[email protected]
export PATH="$HOME/.local/bin:$PATH"

git clone [email protected]:AndreiTelteu/phpmyadmin-desktop.git
cd phpmyadmin-desktop

cd frontend
npm install
npm run build
cd ..

wails3 generate bindings -clean -b -names -ts -d frontend/bindings
gofmt -w *.go
go test ./...

frontend/dist is embedded into the Go binary. The Wails v3 bindings in frontend/bindings/ are generated; do not edit them by hand.

Once native prerequisites are installed, build with the included Wails v3 task:

wails3 task build

List the available task targets or inspect the installed CLI with:

wails3 task --list
wails3 --help

This repository is not ready for production database credentials. The current persistence implementation writes the connection catalogue—including fields for passwords and SSH passphrases—to a local configuration file. Until that is replaced with OS keychain/credential-store integration:

• use only disposable test credentials;
• never commit servers.json or screenshots/logs containing connection data;
• do not expose database ports publicly as a workaround;
• prefer SSH key authentication and strict host-key verification in the eventual tunnel implementation.

The next meaningful implementation milestones are:

1. Build a validated connection editor with stable IDs and safe defaults.
2. Move secrets out of servers.json into native secure storage.
3. Run Windows acceptance tests against a disposable MySQL/MariaDB server and SSH bastion, including the real downloaded FrankenPHP/phpMyAdmin runtime.
4. Add clear environment labeling and safeguards so production mistakes are harder to make.
5. Add an update policy/UI for cached component versions, including visibility of artifacts that have no upstream checksum.

Read AGENTS.md before changing code. It documents the intended product boundary, generated-file rules, build order, security expectations, and the known prototype gaps.