Synticore's Workflow Keeps Expanding

By James Steele Seeley

published on May 27, 2026.

Since the April launch article, Synticore Website Compiler has moved toward a more complete local workflow for static-site production. For users, this is best understood as one cumulative release jump: the public tool is gaining a broader GUI, safer publishing, stronger logs, and a more dependable build workflow all at once.

That jump is not a separate reinvention of the tool. It is the next layer of work around the same idea: a compiler for people who want direct control over their source files, but still want stronger automation around building, checking, publishing, and maintaining the finished output. The focus has been practical: make project work easier to inspect, make publishing safer, make builds more dependable, and reduce the amount of manual glue needed around each site.

A Stronger Local Workspace

The browser GUI is a much larger part of the Synticore workflow in this release. It does more than launch tasks and edit project settings. Runtime sessions, task logs, wiki pages, publish actions, config jumps, and global search give the GUI more of a local project console role.

That matters during everyday work. When a watch session is running, users can see active runtime state, open related logs, copy local or LAN URLs, and move between project surfaces without dropping back to terminal history for every step. The goal is not to hide the compiler from technical users, but to make its current state easier to read while work is happening.

The GUI also has a wider set of supporting features: cached config views, preloaded publish setup dialogs, readable Runtime cards, wiki navigation, and direct jumps to important config keys. These changes are less flashy than a new top-level feature, but they make repeated use feel much smoother.

Publishing and Secrets

Another major area of progress is publishing. Synticore has first-class local-only config.secret.json support, compiler-wide secret redaction, rsync publishing, named publish targets, and secret profiles. Shared project behavior can stay in normal project config, while machine-specific paths, destinations, usernames, keys, and other sensitive details can stay local.

For users, this means publishing can be configured more cleanly without mixing sensitive deployment details into the same file that describes the project itself. The browser GUI also reflects that boundary by treating secret config as a separate, reveal-gated surface instead of casually displaying sensitive values.

The practical result is a safer publishing workflow that is still usable. Targets can be selected from the GUI, missing publish setup can guide users back to the right config area, and rsync output is handled with more care so failures and interactive transport behavior are easier to understand.

Smarter Build Behavior

The build pipeline has also grown in ways that help real projects. Token replacement and file-include support reach into more supported text pipelines instead of being limited mostly to HTML-oriented work. Automatic helpers, including title-name and checksum-based file references, make it easier to keep generated output consistent without hardcoding every detail by hand.

Synticore also gained page-tag-aware loop filtering for pages marked no-package or no-sitemap. That gives projects a cleaner way to keep utility pages, examples, or excluded content out of generated lists and packaged output when those pages should not behave like normal public content.

Under the surface, dependency-aware task chains and watch scheduling changes make config-driven rebuilds more predictable. The compiler can resolve which tasks belong together, reduce duplicate work triggered by generated files, and preserve important config diffs during rapid changes.

Logs, Runtime, and Maintenance

Recent work has also made Synticore easier to debug and maintain. Runtime sessions use per-session registry files, lifecycle events, readable display titles, and active/inactive session tracking. The new Runtime log modals can load large files in windows, filter by level, search through entries, and prefer terminal-style companion logs when available.

Setup and upgrade behavior are part of the same public jump. The shared setup runner is designed to be rerunnable, project migrations cover font-icon, secret-config, and package-cache expectations, and rebuild ownership keeps generated font-icon assets under the task that owns them.

These are the kinds of changes that make the compiler feel less fragile over time. A good static-site workflow is not only about producing output once. It also needs to survive upgrades, recover from environment drift, explain failures clearly, and keep long-running projects manageable.

What This Means

The overall direction is clear: Synticore is becoming more than a build script with a name. It is becoming a local production workspace for static websites, with source files, compiled output, project docs, runtime state, logs, publishing, and configuration all treated as connected parts of the same workflow.

For people using Synticore, the benefit of the next public upgrade is less friction. There is more structure around publishing, more visibility into running tasks, more reliable rebuild behavior, and a clearer path for upgrading existing projects. The compiler still stays close to normal web files, but the surrounding tooling is becoming more capable.

The full technical list is best tracked in the changelog. This article is the shorter version: across the next public release, Synticore has moved from a useful compiler into a fuller day-to-day environment for building and maintaining static sites.

Website: synticore.cureinteractive.com
Full changelog: synticore.cureinteractive.com/wiki/changelog