Choose a deployment model

The web server serves browsers and the mobile app. The ExecutionEngine processes media and accesses sources, output folders, and backup targets. A shared database stores metadata, configuration, permissions, and job status. Photos and videos remain on the configured storage. The search coordinator handles AI searches and runs inside the web server by default. Image-based AI search requires a reachable AI service.

Before installation, record service hosts, internal and public addresses, database, storage, service accounts, backup targets, and owners. Two coordinators still depend on the database, web server, and required storage.

Install and commission Sorty

Installers are available for Windows 10/11 x64, Debian 12 or later and Ubuntu 22.04 or later on x64 with systemd, and Raspberry Pi 5 with 64-bit Raspberry Pi OS. The Linux installers use apt. For a standalone Pi, plan for 8 GB RAM, active cooling, and a suitable power supply. The installers need internet access to fetch runtimes and models, plus MySQL for standalone installations. Compare the installer’s SHA-256 hash with the published value before running it.

Standalone

1. Attach the media and backup storage. Use persistent drive letters or mount points. Set permissions for the engine service account.
2. Run the Windows installer with administrator privileges. On Linux, invoke the selected installer with sudo sh, for example sudo sh Sorty-Standalone-Setup-Linux.run.
3. Open https://localhost/ or the address printed by the installer on the installation host. If port 443 is busy, the usual fallback is 8443. Verify the local certificate before trusting it. Create the first Sorty administrator account.
4. Create a workspace, source, and output folder. Test both connections. Sort a small sample and compare the output with the originals. Enable source deletion only after this check.

Separate web server and multiple engines

1. Provision the shared database and separate credentials for the web server and engines. Restrict the database port to the hosts that use it.
2. Install the web server using the database host, port, name, and credentials. The web server installer can initialize an empty database. Check the schema before using an existing database.
3. Run the engine installer on each processing host and point it at the same database. Verify the registered address and engine port from the web server. TCP 8766 is the default. Limit access to web servers and separate coordinators.
4. Name the engines in Sorty, assign their workspaces, and select which engines can process requests together. Each participating engine needs access to the required storage and models. Keep participating services on compatible versions.
5. Verify login, processing, search, and retrieval of originals. For shared storage, test retrieval and processing from different engines. Create the first backup after these checks.

Database and services

The installers use MySQL 8.4. PostgreSQL 16 and SQL Server 2025 are configured manually. SQL Server requires a case-insensitive collation, such as Latin1_General_100_CI_AI. The default ports are 3306, 5432, and 1433, respectively. For remote databases, verify encryption and server certificate validation separately for the web server and engine. Use a protected network or tunnel where a driver cannot reliably verify the server identity.

Set Database:Provider to MySQL, PostgreSQL, or SqlServer in the web server settings. ConnectionStrings:Sorty holds the provider-specific connection string. The engine uses DatabaseProvider, DatabaseHost, DatabasePort, DatabaseName, DatabaseUsername, and DatabasePassword. Both services must point to the same provider and database. Use a separate provisioning account for schema changes. Protect credentials and keep them out of tickets and log excerpts.

Verify a manually provisioned database

Create the database using the provider’s administration tools. PostgreSQL uses the public schema and SQL Server uses dbo. Use a DNS name covered by the server certificate. The web server can use SSL Mode=VerifyFull for PostgreSQL with the appropriate root CA. For SQL Server, use Encrypt=True and TrustServerCertificate=False with a valid certificate. Test connectivity, processing, and recovery with the chosen database before production use. Configure the same provider on separate coordinators.

Manage the schema

Run the installed web application from its installation directory with db-init for an empty database, db-check to validate it, or db-migrate to upgrade it. An example using the bundled runtime on Linux:

sudo -u sorty /opt/sorty/dotnet/dotnet Sorty.Frontend.Web.dll db-check

On Windows, run dotnet .\Sorty.Frontend.Web.dll db-check from the web server installation directory and use the bundled runtime if required. Before migrating, verify a backup, stop affected services during maintenance, and follow the release notes for the starting version. Run the migration and schema check with the new application. Older databases may need intermediate updates before the first versioned migration, 20261122. If a migration stops partway, review the error and compare the schema against the backed-up starting point.

Services and permissions

Fresh Windows installations use separate virtual accounts under NT SERVICE. Updates preserve existing service identities. Check the active account in Windows Services. Drive letters mapped in an interactive session may be unavailable to a service. Use a suitable storage adapter or a UNC path the service account can access. On Linux, check persistent mounts, access for the sorty account, and preservation of the engine identity under /var/lib/sorty.

Networking and HTTPS

For internal access, use a DNS name or VPN and a trusted certificate chain. For direct public access, expose only the web server. Sorty normally uses port 443 for HTTPS and 80 for redirects and ACME validation. For Let’s Encrypt, verify public A and AAAA records, forwarding to the correct host, and reachability on port 80. With an uploaded certificate, check the hostname, full chain, and expiry. Verify browser and app access from a second device.

With a same-host proxy, terminate HTTPS on Apache or nginx and forward traffic to http://127.0.0.1:5000. Set Kestrel:Endpoints:Http:Url to that address and remove the remaining public backend binding. Forward WebSockets. The proxy should replace incoming forwarding headers with the real client IP and the HTTPS scheme. Verify login, interactivity, and share links using the public name.

Run initial setup locally. For setup from a trusted network, temporarily add its CIDR under **FirstSetup__AllowedNetworks__0**. Verify the client IP and remove the exception after setup. Keep the database, engines, coordinators, and AI services on the protected network.

Search and AI services

Standard search uses stored attributes. For semantic search, enable the feature under System after the web server and all enabled engines pass their model self-tests. Analyze existing media to generate missing embeddings and check coverage. Semantic search can use local models.

Under AI Servers, add a service such as Ollama, vLLM, or llama.cpp with its address, interface, model, and key if required. Assign the intended workspaces. Start with low concurrency and test latency and quality. Restrict internal services to participating Sorty hosts and verify the trust chain for HTTPS. External AI services may receive media. Review which data may leave the installation before enabling one. Transcription requires a Whisper-compatible service. An optional translation service receives search text. Check the setting for sending people’s names. Schedule the initial AI review per workspace for periods with spare capacity.

Operate primary and backup coordinators

1. Install the primary coordinator in slot 1 and the backup in slot 2. Both need the same database and access to the required engines and AI services.
2. Check SortyCoordinator1 and SortyCoordinator2 on Windows or sorty-coordinator-1 and sorty-coordinator-2 on Linux. The default local ports are 15081 and 15082. The services poll the database. The installer creates no inbound firewall rule for them.
3. Set **SearchCoordinator__RunInWeb=false** on the web server and restart it. Run a test search. For optional HTTPS wake signals, set **SearchCoordinator__Address** on each coordinator, configure **SearchCoordinator__AllowedAddresses__0** and **__1** as needed on the web server, and set the same random **SearchCoordinator__SignalKey** of at least 32 characters on all participating services. Use trusted certificates and limit the inward firewall rule to the web server.
4. During maintenance, stop the primary after it accepts an approved test search. Verify completion by the backup and restart the primary. To return to embedded operation, stop both separate services, remove the setting that disables the embedded coordinator, and restart the web server.

Storage, workspaces, and permissions

Sources require read access. Outputs and backups require write access, plus delete permission for cleanup. Source deletion requires separate delete permission on the source. Use a location managed exclusively by Sorty for writable rclone profiles. Give users, cameras, and synchronization tools a separate intake location. Test each adapter from its assigned engine using disposable files.

For WebDAV, limit origins with SORTY_WEBDAV_ALLOWED_ORIGINS. Configure a private CA per origin with TrustedCaPem in SORTY_WEBDAV_TLS. Keep certificate verification active. S3, Azure Blob, and OneDrive verify TLS certificates. Check each additional profile against the trust chain in your installation. Protect backups and exports because they may contain storage credentials.

For S3, provide the bucket, region, and an identity authorized for the prefix. For an S3-compatible service, check the HTTPS endpoint. For Azure Blob, use the HTTPS account address, container, and an authorized service identity. For Google Cloud Storage, specify the bucket, optional project and prefix, and service account key. Monitor OAuth expiry and revocation and test credential renewal. Check locking support for writable WebDAV and confirm the user path on Nextcloud.

Organize collections into separate workspaces. Viewers read, users maintain content, workspace administrators manage their collection, and Sorty administrators manage system-wide settings. Require two-factor authentication for administrators where feasible. Verify originals, shares, and ZIP downloads with a regular test account. Review share links when revoking access.

Hardware and routine operations

These are sizing examples. Account for collection size, resolution, video length, models, available VRAM, and storage throughput. Reserve capacity for models, previews, temporary files, and growth. Run Sorty’s performance adjustment with representative media. Measure CPU, GPU, and memory use. Tune job concurrency and detection size gradually. If AI search is slow, check model size, available VRAM, queuing, and network latency.

Schedules and notifications

Set schedules per workspace. Check the displayed time zone and next run, including before daylight-saving transitions. Test rule changes with a small sample. Reorganization can replace outputs and clean up obsolete copies. A nightly storage check helps detect missing or moved files. Stagger processing and backups when both compete for limited storage bandwidth.

Monitor engine status, blocked jobs, free space, backups, certificate expiry, and AI services. Configure SMTP under System with STARTTLS or TLS as needed and send a test message. Keep service hosts synchronized in time and assign responsibility for alerts.

Backups, recovery, and upgrades

Back up the media, database, settings, certificates or renewal procedure, and engine identity. Enable the nightly database backup under System. Select the engine, target folder, time, and retention. Check write permissions and free space. Sorty’s PostgreSQL and SQL Server backups contain the data. Initialize a compatible empty schema before restoring the data. Keep a versioned, separately protected off-system copy and practice restoring to isolated destinations.

Rehearse a restore

Check that the compressed archive is readable. Restore it to an isolated database with the provider’s tool. Check the schema with the matching Sorty version, then verify access, workspaces, and media paths. Record how long the restore takes and how old the latest usable backup is. Make sure the backup is accessible without the original host.

Stop affected services for recovery. Restore compatible copies of the database, media, and configuration. Verify the schema, permissions, and certificates. Start the web server, engines, and coordinators in a controlled sequence. Verify login, roles, originals, and processing. For a blocked job, record the last error and check the job and storage before editing managed files. Retry or undo the job once the cause is clear. Undoing a job may restore removed originals and delete Sorty-created outputs.

Upgrade or uninstall

Use the new installer for the original platform and role. Schedule downtime, allow work to stop safely, and take a verified backup. Apply any required schema updates and bring the participating services to a compatible version. Verify login, engine connectivity, a sample job, and a search. Keep a matched application and database version for rollback.

On Windows, uninstall through Settings → Apps. Choose whether to keep the local database and settings. On Linux, stop and disable the installed services with systemctl, remove their service definitions, and reload systemd. Remove the installed files for the affected roles and the local trust certificate where applicable. Remove the database, settings, or media only after verifying the backup and deciding what to retain.

Troubleshooting

For support, record the version, service role, platform, time, error, and last successful step. Remove passwords, tokens, and private media from evidence.