The pieces that run your site, what each one does, and how they connect. Plain names throughout, with the real technical name in grey — both stay the same on every line, so nothing gets confusing.
Two pictures cover everything: how the site runs day to day, and how Akaash’s updates reach it.
Visitors read your site and you edit it — both arrive through the same path to The Server, which runs three things side by side.
One cloud computer, on 24/7 (Bangkok). It runs:
When Akaash improves the design or adds a feature, the update travels this path on its own.
The key point: an update only replaces the Website. Your Database (text) and Image storage (photos) are never touched — your content can’t be overwritten by an update.
The same system in a little more depth — for when you want to know exactly what’s happening.
Your whole site lives on a single small computer rented from Amazon (AWS), running around the clock in their Bangkok data centre. Keeping it in one place keeps things simple and inexpensive.
That one server runs three things together: the Website people read, the Admin dashboard you log into, and the Database that remembers everything you write.
When someone visits, their request first reaches Cloudflare — which turns your web address into directions, adds the padlock (a secure, encrypted connection), and screens out bad traffic.
It then hands off to the Website, which assembles the page using your words from the Database and your pictures from Image storage. All in about a second.
You sign in to the Admin dashboard and change a page, story or resource. Your text is written to the Database; any photo you upload goes to Image storage.
It’s live straight away — no waiting and no developer needed. This is yours to use whenever you like.
When Akaash changes the design or features, he saves the new Code to GitHub. A robot assembly line (Build & deploy) packages it and the Server installs the new Website automatically.
Your text and photos are left exactly as they were.
Every connection uses HTTPS — the encrypted padlock. A full copy of the Database is saved automatically every day, on a 7-day rolling backup: the last seven days are always kept, and anything older drops off.
So if anything ever went wrong, your content from any point in the past week can be restored.
The site sends a few emails — password resets, and alerts when someone fills in a contact or enquiry form. These go out through your own Gmail account, so they come from your real address.
Every name on this page, in one place — plain term, technical name, and what it means.
The private screen where you sign in to write and edit your website’s pages, stories, resources and photos.
A fresh copy of the Database is saved every day; the most recent seven are kept and older ones are removed — so the last week is always recoverable.
The automatic step that packages new Code into a ready-to-run version and installs it on The Server — no manual work.
The front door of your site: it turns your web address into directions to The Server, secures the connection, speeds the site up, and blocks bad traffic.
The website’s source — the instructions that make it look and work the way it does. Akaash keeps and changes it here.
The website’s memory. Every word and edit you save is stored here, on The Server.
The encrypted, secure connection shown by the padlock in the browser, so information can’t be read in transit.
A dedicated home for every photo you upload, kept separate from your text so pages stay fast.
The finished, ready-to-run bundle of the website that the build step produces and The Server runs.
A small computer rented from Amazon, on 24/7 in Bangkok, where your live website actually runs.
How the site sends emails (password resets, form alerts) — through your own Google account.
cognovagrowth.com — what people type to reach you. It doesn’t change.
Everything above, with the real names, specs and the reasoning behind each choice. Same system — just seen one level down.
Four providers, each with a clear job. Keeping responsibilities split this way means any one can be swapped without disturbing the others.
The site is a Next.js 16 app written in TypeScript (JavaScript with a type system). Next.js is a React framework: it renders pages on the server for speed and SEO, then “hydrates” them so they’re interactive in the browser. It runs on the Node.js 22 runtime and is compiled into a self-contained server bundle.
Payload is an open-source headless CMS that runs inside the same Next.js app — not a separate service. It defines the content model (collections like Pages, Resources, Media, Testimonials, Enquiries), provides the /admin dashboard Manisha logs into, handles authentication and access control, and auto-generates REST & GraphQL APIs. It reads and writes content to Postgres through the Drizzle ORM adapter.
PostgreSQL 16 is a relational (SQL) database — the system of record for all content: every page, story, resource, testimonial and enquiry, plus the metadata for each image (filename, generated sizes, alt text). Payload maps each collection to Postgres tables (~167 of them here). It’s self-hosted in a container on the server — not Amazon RDS — so the entire site runs on one machine.
AWS EC2 (Elastic Compute Cloud) rents virtual machines by the hour. This one is a t4g.micro — a small, burstable, ARM-based instance:
Graviton is Amazon’s own ARM processor — the same broad architecture as Apple Silicon and phone chips — which is cheaper and more power-efficient per unit of work than Intel/AMD x86. Burstable means it runs at a modest baseline and banks CPU credits while idle, spending them during short spikes — ideal for a low-traffic site. Because the chip is ARM, the app image must be built for arm64 — which is exactly what the CI pipeline targets.
A way to package an app with everything it needs to run — runtime, libraries, config — into a portable image, then run that image as an isolated container. The same image behaves identically on any machine, which removes “works on my laptop” surprises.
Three containers run side by side, wired together by Docker Compose (a short YAML file): web (the Next.js + Payload app), db (PostgreSQL), and caddy (the web server). Compose starts them, connects them on a private network, and restarts any that crash.
A server that sits in front of your app: it receives incoming requests and forwards them on, typically adding TLS, compression, caching or routing along the way.
Caddy is the reverse proxy on the instance. It terminates HTTPS on the box, adds security headers, and routes requests to the app. It’s the on-server counterpart to Cloudflare at the edge.
Cloudflare sits between visitors and the server (“in front of the origin”), doing three jobs. DNS turns cognovagrowth.com into the server’s IP address.
With the “orange-cloud” proxy on, traffic flows through Cloudflare instead of straight to the server. That lets Cloudflare terminate TLS at the edge (the padlock), hide and protect the server’s real IP, absorb DDoS attacks, filter bad bots, and cache responses — all before anything reaches the box.
A Content Delivery Network is a global network of edge servers in many cities that cache content close to users. A visitor in Bangkok is served from a nearby node rather than waiting on a round-trip across the world — faster pages and less load on the origin. Cloudflare’s CDN fronts both the website and the images.
A service for storing files (“objects” — images, PDFs, video) addressed by a key, rather than via a traditional filesystem or database. It scales endlessly and is inexpensive.
Cloudflare R2 is S3-compatible object storage (the same API as Amazon S3) but with no egress fees and a 10 GB free tier. The bucket cognova-media holds every uploaded image and is served publicly through Cloudflare’s CDN at media-cdn.cognovagrowth.com. Keeping images here — off the server and out of the database — keeps the box tiny and pages fast.
Continuous Integration / Continuous Deployment — automating the path from “code committed” to “running in production,” so releases are repeatable, fast and hands-off rather than manual.
The code lives in a private GitHub repository. GitHub Actions (GitHub’s built-in automation) runs the pipeline: on every push to main it spins up a throwaway Postgres (loaded from the latest backup so pages can pre-render), builds the ARM64 Docker image, authenticates to AWS via OIDC (short-lived tokens — no AWS keys stored in GitHub), and pushes the image to Amazon ECR (Elastic Container Registry — a private store for Docker images).
The server pulls from there: a small systemd timer checks ECR every two minutes using the machine’s own IAM role (temporary AWS credentials granted to the instance — again, no stored secrets), and if the image changed, swaps in the new version. Nothing needs inbound access to the box, so the firewall stays shut.
A daily job runs pg_dump, gzips the database, and uploads it to R2 on a 7-day rolling schedule — the last seven days are kept and older ones pruned. Connections are HTTPS end-to-end, and transactional email goes out via Gmail SMTP.
The server sits entirely behind Cloudflare. Its AWS firewall (security group) accepts inbound web traffic on 80/443 only from Cloudflare's published IP ranges, and SSH only from a single admin IP — so the origin can't be reached directly, and Cloudflare's WAF / DDoS protection can't be bypassed by hitting the IP.
TLS is Full (Strict) — encrypted and certificate-validated end to end. Caddy serves auto-renewing Let's Encrypt certificates obtained via DNS-01 (proven by a DNS record, so no inbound port is needed even behind the firewall). The instance metadata service is IMDSv2-only, the secrets file is chmod 600, Postgres is never exposed to the network, and OS security patches apply automatically.
On top of that, GuardDuty (AWS threat detection) flags suspicious behaviour and fail2ban bans repeated failed SSH attempts.
Four independent layers watch the site and email the team if anything's wrong — deliberately overlapping, so no single failure goes unseen.
1 · External uptime monitor — a separate machine pings the site every minute; independent of AWS, so it catches a total outage the server couldn't report itself. 2 · On-box watchdog — checks disk, container health, app health and certificate expiry every 10 minutes. 3 · Failure hooks — a failed backup or deploy emails the logs instantly. 4 · AWS CloudWatch — alarms on CPU-credit exhaustion (the burstable-throttle risk) and instance health checks, delivered via SNS.
A visitor hits cognovagrowth.com → Cloudflare (DNS, TLS, CDN cache, security) → the EC2 server → Caddy → the Next.js app, which asks Payload for content, Payload queries Postgres, and image tags point at R2 via the CDN — the page is assembled and returned. Edits travel the same path in reverse through /admin; code changes flow GitHub → Actions → ECR → the server.