SupaAI.cloud — Project Overview and Technical Architecture

Document type: Technical project overview
Audience: Academic reviewer, software developers, IT colleagues
Updated: October 13, 2026
Status: Describes the current design and documented deployment; specific verification items are identified separately.

1. Executive Summary

SupaAI.cloud is a full-stack web application for presenting independently developed software projects and organizing technical notes. The public-facing website is intentionally simple, with three main navigation items: Home, Project List, and Notes. An administrative workflow supports managing project and note content. Notes use Markdown and have a visibility setting intended to distinguish publicly published notes from owner-only content.

The application is deployed on a Microsoft Azure virtual machine running Ubuntu Linux. Its documented stack includes Next.js/Node.js for the web application, PostgreSQL for persistent data storage, Nginx as the HTTPS-facing reverse proxy, and PM2/systemd for process and service management. The deployment also includes an encrypted, automated off-site backup workflow using Azure Blob Storage and Azure-managed authentication.

The project is intended to demonstrate more than front-end implementation: it covers full-stack application design, data persistence, Linux operations, security boundaries, cloud deployment, and disaster-recovery planning.

2. Purpose and Scope

The application addresses two primary needs:

1. Project portfolio: Present side projects developed during study, independent learning, and spare time.
2. Technical knowledge base: Organize notes and selectively publish Markdown-based technical content.

The public navigation remains deliberately limited to Home, Project List, and Notes. Administrative interfaces are distinct from this public navigation.

3. Functional Overview

Area	Purpose	Intended audience
Home	Introduction and entry point to the website	Public visitors
Project List	Showcase independently developed projects	Public visitors
Notes	Browse publicly available technical notes	Public visitors
Administrative content management	Create and maintain projects and Markdown notes	Authorized administrator
Note visibility	Determine whether a note is available publicly or owner-only	Administrator / access-control layer

3.1 Markdown Note Management

Markdown is used as the authoring format for notes, allowing content to be structured with headings, lists, code blocks, and links. Each note has an availability/visibility configuration. The intended behavior is:

• Public: The note can appear in the public notes listing and be opened by visitors.
• Private: The note is excluded from the public listing and its content is intended to be accessible only to its authorized owner.

Security distinction: Hiding a private note from a browser list is not sufficient access control. The backend must also enforce authorization for direct links, content API endpoints, and any other retrieval method. End-to-end enforcement should be verified in application code and tests before describing it as a validated security guarantee.

3.2 Theme

The site currently follows a dark visual design. A user-selectable light/dark theme switch is not currently part of the documented implementation.

4. System Architecture

Rendering diagram…

Architecture notes: The diagram shows the major documented responsibilities rather than every implementation module or network boundary. The authentication/authorization node describes a required responsibility; the exact authorization implementation should be verified separately. Storage locations and package versions should be checked against the running host before publishing an operations runbook.

5. Technology Stack and Hosting

Layer	Technology / responsibility
Cloud hosting	Microsoft Azure virtual machine
Operating system	Ubuntu Linux (documented as 24.04 LTS)
Application	Next.js and Node.js
Database	PostgreSQL (documented as version 17)
Reverse proxy	Nginx; HTTPS handling and routing to application service
Application process	PM2, integrated with systemd for startup and recovery
Scheduled operations	systemd services and timers
Off-site backup storage	Azure Blob Storage
Azure service authentication	Managed Identity for the backup/storage workflow
Content format	Markdown for technical notes

This division separates user-facing features from infrastructure concerns, allowing the application to be operated and maintained as a server-hosted service rather than merely a static website.

6. Content Visibility Flow

Rendering diagram…

Verification requirement: Confirm that public list APIs, individual note endpoints, any server-side rendering routes, and search/indexing surfaces consistently enforce these rules. The above is the intended flow, not a claim that all possible bypasses have been independently tested.

7. Request and Deployment Flow

Rendering diagram…

The current deployment is hosted on the Azure VM. The application and operational services are managed at the Linux host level. Changes to the application should be tested before production rollout; this document does not claim that a fully automated CI/CD pipeline has already been implemented.

8. Automated Off-Site Backup and Recovery

The deployed backup mechanism is intended to protect application data against a single-server failure by storing encrypted copies outside the application VM.

Documented configuration:

• Schedule: Daily at 8:30 PM America/Toronto local time (the timer follows the local time zone).
• Scheduler: systemd timer invokes a dedicated backup service.
• Source material: PostgreSQL database, uploaded assets, and selected protected application configuration.
• Protection: Archive encryption before uploading.
• Destination: Azure Blob Storage, off-site from the application VM.
• Azure authentication: Managed Identity, avoiding a long-lived storage account key in the service configuration.
• Notifications: A component was added for success/failure notification; end-to-end email delivery should be confirmed in operational monitoring.

Rendering diagram…

Operational caveats: Backup success does not by itself demonstrate successful restoration. A documented restore procedure and periodic restore tests should be part of the disaster-recovery plan. Likewise, a notification script existing in Git does not prove that all success/failure messages are being delivered reliably.

9. Security and Operational Considerations

The architecture separates public browsing, administrative editing, and operational backup responsibilities. Principal security concerns include authenticated administrative access, server-side enforcement of private-note visibility, HTTPS, controlled service permissions, encrypted backups, and managed access to off-site storage.

The backup service is operated using dedicated service configuration and systemd isolation. Sensitive values should not be included in shared reports, repository commits, diagrams, or screenshots. For colleagues reviewing this project, share architecture and operational behavior without passwords, tokens, database connection strings, or private blob URLs.

10. Implementation Status and Evidence Boundaries

Topic	Status based on available project records	Verification needed before an exact claim
Azure/Linux hosting	Deployed	Confirm current VM image/version if reporting exact patch level
Next.js/Node.js/PostgreSQL/Nginx/PM2	Documented deployed stack	Confirm package versions on current production host
Three-item public navigation	Project design described	Confirm current deployed UI matches design
Markdown notes and public/private setting	Feature/design described	Verify all endpoints enforce visibility and authorization
Dark theme	Current UI/design described	Confirm theme behavior on production build
Off-site encrypted backups	Deployed and scheduled	Verify recent successful archives and conduct restore test
Daily backup time	Confirmed systemd timer at 20:30 local time	Re-check schedule after configuration changes
Success/failure email notifications	Notification code and service configuration committed	Confirm service activation and real delivery of both outcomes
Backup retention cleanup	Future enhancement	Define retention requirements and implement safely
CI/CD	Not asserted	Assess separately before claiming automation

11. Future Development

1. Light and dark theme selection: Allow users to switch visual themes and persist their preference.
2. Backup retention and lifecycle controls: Define how many daily/weekly backups to keep and automatically retire expired objects while preserving recovery coverage.
3. Administrative audit logs: Record who changed a note's visibility, what changed, and when.
4. Access-control testing: Add explicit tests for private-note access via direct URLs, APIs, and indexes, not only hidden list entries.
5. Disaster-recovery validation: Document and periodically test the PostgreSQL/assets restore process.
6. Deployment repeatability: Improve deployment instructions and consider CI/CD once current release procedures have been documented and verified.

12. Conclusion

SupaAI.cloud combines a lightweight personal portfolio and technical note management interface with a real cloud-hosted operational environment. The project illustrates the integration of web application development, relational data storage, access-control design, Linux service management, encrypted off-site backups, and practical reliability engineering. Its deliberately minimal public interface is supported by a more substantial deployment and maintenance architecture, which can be expanded as the project evolves.

---