AI-NOW Website Deployment Architecture: How It Differs from Traditional Deployment

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

DimensionCommon Direct-Overwrite DeploymentAI-NOW V2.3
Publishing methodFTP, SFTP, rsync, or manually replacing live filesGitHub Actions CI/CD and a controlled server-side deployment script
Version identityFilenames, timestamps, or manual notesUnique release ID, full Git commit SHA, and release.json
Build validationMay upload a locally built site directlyCI validation precedes CD, which is triggered only by qualifying successful CI
Release stagingFiles may overwrite the live directoryUpload to releases/, then validate and publish to verified/
ActivationVisitors may encounter mixed files during copyingAtomically switch the release symlink, then recreate Nginx
Privilege separationUpload account may directly modify live filesSeparate upload-writable area from root-managed verified releases
Reusing a release nameExisting directories may be overwrittenRENAME_NOREPLACE rejects overwriting an existing verified release
Concurrent deploymentsMultiple deployments may interfereflock serializes deployment script execution
Post-deployment validationOften a manual homepage checkLocal HTTPS check verifies the expected release.json
Failure recoveryManual backup restoration or repairV2.3 attempts automatic rollback during eligible failure stages
TraceabilityDepends on operational recordsGit 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_NOFOLLOW to 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_NOREPLACE for atomic snapshot publication without overwriting an existing release.
  • flock to 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:

  1. Restore the current symlink to the previous release.
  2. Recreate the Nginx container.
  3. 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:

ItemObserved Result
GitHub CISuccessful; run ID 41495512006
CDRun ID 41495582692; still running when queried, with the new release subsequently observed live
Production releasegh-56c84c953ede-41495582692
Production commit56c84c953edebb775a805e20917e1e088d4eb7c9
current symlinkPointed to that release
HTTPS release.jsonRelease and commit matched
Public HTTPSHTTP/2 200
Caddy / NginxBoth containers reported running
Deployment runbookdocs/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

Leave a Reply

Your email address will not be published. Required fields are marked *