AI-NOW Production Deployment V2.3
Technical architecture overview and comparison with conventional deployment practices
Baseline date: November 2, 2026
1. The Fundamental Difference
Conventional website deployment often centers on copying updated files directly into the directory currently serving visitors. This approach can expose a mixture of old and new files during a transfer, make the deployed version difficult to identify, and require manual intervention after failures.
AI-NOW separates building, validation, upload, isolated snapshot creation, publication, service activation, health verification, and failure recovery into distinct stages. Rather than treating deployment as a file-transfer task, it uses Git commits and release manifests to identify and verify each release.
In one sentence: conventional deployment focuses on getting new files onto a server; AI-NOW V2.3 focuses on proving which validated release is serving traffic and recovering when activation fails.
2. Architecture Overview
Developer (Linux / Git)
|
| git push origin main
v
GitHub Repository
|
v
GitHub Actions CI
- Build and validate Astro
- Successful qualifying CI triggers CD
|
v
GitHub Actions CD
- Check out the CI-validated commit
- Build the static website
- Generate release.json
- Upload to releases/<release-id>
|
v
DigitalOcean / Ubuntu 24.04
/srv/ai-now/web/
releases/ <- CI/CD upload area; not served directly
verified/ <- Root-managed validated release snapshots
current -> verified/<active-release>
|
v
ai-now-deploy V2.3
- Deployment locking
- File and path validation
- Secure snapshot creation
- Atomic publication and symlink switch
- Nginx container recreation
- HTTPS health verification
- Attempted rollback on eligible failures
|
v
Nginx (static content) -> Caddy (HTTPS reverse proxy)
|
v
https://ai-now.tech
Astro generates static assets. Nginx serves those assets, Caddy provides the public HTTPS reverse proxy, and Docker Compose manages the containers.
3. Conventional Deployment vs. AI-NOW V2.3
| Dimension | Common Direct-Overwrite Deployment | AI-NOW V2.3 |
|---|---|---|
| Publishing method | FTP, SFTP, rsync, or manually replacing live files | GitHub Actions CI/CD and a controlled server-side deployment script |
| Version identity | Filenames, timestamps, or manual notes | Unique release ID, full Git commit SHA, and release.json |
| Build validation | May upload a locally built site directly | CI validation precedes CD, which is triggered only by qualifying successful CI |
| Release staging | Files may overwrite the live directory | Upload to releases/, then validate and publish to verified/ |
| Activation | Visitors may encounter mixed files during copying | Atomically switch the release symlink, then recreate Nginx |
| Privilege separation | Upload account may directly modify live files | Separate upload-writable area from root-managed verified releases |
| Reusing a release name | Existing directories may be overwritten | RENAME_NOREPLACE rejects overwriting an existing verified release |
| Concurrent deployments | Multiple deployments may interfere | flock serializes deployment script execution |
| Post-deployment validation | Often a manual homepage check | Local HTTPS check verifies the expected release.json |
| Failure recovery | Manual backup restoration or repair | V2.3 attempts automatic rollback during eligible failure stages |
| Traceability | Depends on operational records | Git commit, GitHub Actions run ID, and release manifest |
Scope note: “Conventional deployment” here means a common direct-overwrite approach. Mature traditional deployment systems can also provide versioning, atomic releases, and rollback.
4. Core Engineering Design
4.1 CI and CD Are Separate
AI-NOW does not deploy merely because any GitHub Actions workflow succeeds. CD is triggered through workflow_run and checks that the originating CI run succeeded, came from a push to main, and belongs to the expected repository.
This reduces the risk of a manual CI invocation or an ordinary pull-request validation inadvertently deploying to production.
4.2 Every Release Has a Verifiable Identity
Example release ID:
gh-56c84c953ede-41495582692
Corresponding HTTPS manifest:
{
"release": "gh-56c84c953ede-41495582692",
"commit": "56c84c953edebb775a805e20917e1e088d4eb7c9"
}
Operators can compare the GitHub commit, the server’s current symlink, and the public /release.json endpoint. This helps detect a common operational mistake: assuming a successful Git push means the same version is already live.
4.3 Uploads Are Isolated from Verified Production Releases
/srv/ai-now/web/
├── releases/ # Incoming release uploads
├── verified/ # Validated release snapshots
│ ├── gh-4703838fa7ad-41493485863/
│ └── gh-56c84c953ede-41495582692/
└── current -> verified/gh-56c84c953ede-41495582692
The releases/ directory is not the public document root. The deployment script validates files and the manifest before copying content into a protected snapshot. Unverified uploads do not automatically become production content.
4.4 Safer Filesystem Operations
V2.3’s secure snapshot workflow includes:
O_NOFOLLOWto avoid following symbolic links during file access.- Rejection of disallowed symlinks, hardlinks, and nonregular files.
- File-state checks before and after copying to reduce replacement-race risks.
- Ownership and write-permission checks for protected directories.
RENAME_NOREPLACEfor atomic snapshot publication without overwriting an existing release.flockto prevent simultaneous execution of the deployment script.
These controls reduce risks involving filesystem races, path confusion, and privilege misuse. They do not guarantee protection against every supply-chain attack or server compromise.
4.5 Atomic Release Selection and Container Recreation
Directly overwriting live files can expose visitors to a partially updated site.
AI-NOW prepares a complete validated snapshot first, then atomically changes the current symlink. Docker Compose then force-recreates the Nginx container so its bind mount reflects the selected release directory.
Atomic here describes switching the release pointer. It does not establish a strict zero-downtime guarantee during container recreation. V2.3 prioritizes release consistency, verifiable activation, and recoverability.
4.6 Automatic Rollback
After switching releases, the deployment script checks whether the HTTPS release manifest matches the expected version. If startup or health verification fails at a stage where rollback handling has been established, V2.3 attempts to:
- Restore the
currentsymlink to the previous release. - Recreate the Nginx container.
- Verify that the previous release is serving again.
This behavior passed fault-injection and recovery tests in an isolated environment. Automatic rollback is not a substitute for off-site redundancy, backups, or a complete disaster-recovery plan.
5. Observed Production Verification
As of November 2, 2026, the recorded evidence was:
| Item | Observed Result |
|---|---|
| GitHub CI | Successful; run ID 41495512006 |
| CD | Run ID 41495582692; still running when queried, with the new release subsequently observed live |
| Production release | gh-56c84c953ede-41495582692 |
| Production commit | 56c84c953edebb775a805e20917e1e088d4eb7c9 |
current symlink | Pointed to that release |
HTTPS release.json | Release and commit matched |
| Public HTTPS | HTTP/2 200 |
| Caddy / Nginx | Both containers reported running |
| Deployment runbook | docs/operations/deployment-runbook.md, 128 lines, committed and pushed |
Evidence boundary: These observations establish that the new release was active, its manifest matched, and the site responded over HTTPS. The provided records did not include a separate final query showing CD run 41495582692 as completed success; that outcome is therefore not claimed as independently confirmed.
6. Engineering and Business Value
Reduced Manual Deployment Risk
Engineers no longer need to log into the server for every release, overwrite files by hand, or guess which version is live. A controlled process makes production changes more consistent.
Faster Incident Investigation
When an issue occurs, operators can correlate the release ID, commit SHA, Actions run ID, and active server release to narrow the investigation.
Lower Recovery Effort
Keeping validated releases and attempting rollback after eligible deployment failures is more reliable than searching for old files during an incident. Recovery still depends on the failure mode and availability of a working prior release.
A Reusable Release-Engineering Pattern
The benefit extends beyond a corporate website. AI-NOW now has a reference pattern for future services: traceability, privilege separation, pre-publication validation, post-activation verification, and recoverability.
Stateful or distributed applications would still need additional designs for database migrations, backups, service compatibility, and data recovery. A static site’s rollback mechanism cannot automatically roll back an entire stateful system.
7. Known Limitations and Future Improvements
V2.3 is a verified production baseline. Features not yet implemented should not be described as existing capabilities:
- Documentation-only deployment guard: Not yet configured; documentation-only pushes can still trigger production deployment.
- Automated release retention: No automatic cleanup or approved retention policy has been enabled.
- Continuous monitoring and alerting: Deployment-time health checks do not amount to independent 24/7 monitoring.
- Comprehensive disaster recovery: Host failure, network outages, certificate problems, and backup restoration require separate planning.
- Strict zero-downtime SLA: Container recreation has not been demonstrated to meet a zero-downtime guarantee.
These are candidates for future operations work, not prerequisites for recognizing the current validated release as a stable baseline.
8. Conclusion
What distinguishes AI-NOW’s deployment from a common direct-overwrite workflow is not the number of tools involved. It is the engineering discipline: each release has an identity, critical stages are validated, uploaded artifacts are isolated from production snapshots, and a defined recovery path exists when activation fails.
Conventional deployment asks: “Were the new website files uploaded?”
AI-NOW V2.3 asks: “Which validated release is serving users, how can we prove it, and how can we recover if activation fails?”
That is the shift from basic website maintenance to production release engineering.
Project: AI-NOW Website
Deployment: V2.3
Production: https://ai-now.tech
Repository: https://github.com/AI-Now-Inc/ai-now-web
Document status: Technical architecture overview / Verified baseline
