diumWe ship as asq.php (local bootstrap) + remote JS bundle (versioned application code). Operators run a single PHP file on their server; the application logic lives at our CDN. Managed-SaaS UX, operator-sovereignty narrative, lightest infra footprint in the category.
Platform decisions look like product decisions and behave like architecture decisions. The buyer who picks a community platform on logos and pricing tiers ends up litigating the choice every 18 months; the buyer who picks on architectural axes, real-time presence, long-form retrieval, event lobby depth, monetization surface, P2P privacy, self-hostability, picks once and stays. Why We Ship as asq.php + Remote Shell Instead of a Docker Image sits inside that buyer-grid frame. The fast answer is the wrong answer; the deliberate answer compounds.
Why not Docker
Docker is great for stateful enterprise apps. It's overkill for a PHP file that boots a remote shell. Most buyers don't want to operate a containerized stack to run a community forum; the Docker requirement loses us deals before the demo.
What asq.php does
Reads asqconfig.php for tenant config. Signs a short-lived bootstrap envelope. Emits HTML shell + bootstrap JSON inline. Loads remote CSS + JS via versioned URLs with SRI. Sets security headers (CSP, Permissions-Policy, X-Frame-Options). Done.
Why the remote bundle
We ship application updates without operators having to re-deploy. We canary new versions to 5% of tenants before global rollout. We pin enterprise tenants to known-good versions. We kill-switch a bad release at the platform level. None of this is possible if the operator has a frozen Docker image.
What this means for the operator
Drop asq.php on a server. Edit asqconfig.php with your tenant ID. Done. The application updates itself; the data stays on your infra. The operator burden is the lowest in the self-hostable forum category.
Why the comparison conversation looks different in 2026
Three forces converged. The chat-camp added forum features but the underlying scroll model did not change. The forum-camp added real-time but the underlying topic model did not change. A new generation of buyers, alumni offices, association leads, conference operators, cohort founders, entered the market needing a shape neither camp ever built for. The honest comparison post in 2026 is not "Discord vs Discourse." It is "which two of the six axes does your community need to win on."
The decision frame
Run the two-question test. (1) How often does your community google its own back-catalog? Often → forum-camp wins on retrieval. Rarely → chat-camp wins on presence. (2) How many live events do you run per quarter? 0-1 → any platform works. 2+ → you need event lobby depth as a top-three axis or you will pay the duct-tape tax forever. Three answers each, nine combinations, almost every platform conversation we sit in on collapses to the right answer once these two are honest.
The third question, when it applies, is the sovereignty test: do you operate in a regulated industry, an advocacy context, or any space where data-residency and operator control are procurement requirements? If yes, the SaaS-only options drop out and the matrix narrows to two or three viable choices. The buyers who skip this question discover it the hard way during the security review.
A pattern from the field
We see the same pattern across the operators we work with. The teams who treat Why We Ship as asq.php + Remote Shell Instead of a Docker Image as an upstream design decision: encoded in the platform's defaults, surfaced in the operator dashboard, and audited as a standing line item in the quarterly review: see the downstream metrics move within 60-90 days. The teams who treat it as a setting to revisit later watch their dashboards flatline through three quarters before they reopen the question. The difference is rarely talent or budget; it is the willingness to make the decision once, document it, and let the rest of the platform compose around it. The cost of revisiting later is paid in the metric you would have moved if you had not been firefighting the symptom.
Mistakes that cost two-year regret cycles
- Picking on perceived brand affinity rather than architectural fit.
- Letting the founder's personal Discord habit drive the company-community decision.
- Treating "free" as the deciding factor without computing the per-engaged-member cost across 12 months.
- Buying the platform with the longest integration list and never integrating the things that mattered.
- Skipping the migration math on the existing platform and discovering the lock-in only at year two.
What to do before your next renewal
Print the six-axis matrix. Cross out the column for the platform you currently run. Score the remaining columns against your community's actual top two axes. If the score gap between your current platform and the leader on your two axes is less than two points combined, stay. If the gap is three or more, the migration math is in your favor; start scoping a 14- or 21-day pilot. The honest math saves the next two years of accumulated workarounds. Why We Ship as asq.php + Remote Shell Instead of a Docker Image is part of the audit.
The takeaway
Comparison posts are written badly because they are written for clicks. The comparison conversation that actually serves the buyer takes the architectural axes seriously, lists the honest weaknesses of every option (including the author's own), and gives the reader a frame they can re-apply when the next platform launches. Why We Ship as asq.php + Remote Shell Instead of a Docker Image is part of that frame. We invite you to disagree with our scores, run the audit yourself, and tell us where we got it wrong, that is the contribution this category needs more of, not less.