I built something most developers would probably tell me not to build:
A production web backend in raw C++20.
Building a production web server in raw C++20.
No frameworks. No external libraries.
Zero dependencies beyond the OS itself.
Not because I had to. Because I wanted to understand
infrastructure at the lowest level possible.
This is the full story — every obstacle, every fix,
every command — from a blank CLion project to a live
HTTPS secured domain at aureonops.dev.
Why C++?
Most backend tutorials point you toward Node.js,
Python, or Go. Fast to set up, large ecosystems,
plenty of tutorials.
But I kept asking the same question:
What's actually happening underneath?
C++ forced me to find out. Every connection, every
socket, every HTTP response — I had to build it
myself or it didn't exist.
Initial local observations:
- Small native binary
- Very low memory usage
- Fast startup
- No framework/runtime dependency layer
Formal benchmarks are planned for a future release.
The Stack
Before we get into the journey, here's what we
ended up with:
Engine → C++20 (raw WinSock2 / POSIX sockets)
OS → Ubuntu 24.04 LTS
Proxy → Nginx
DNS / CDN → Cloudflare
Security → SSL/TLS + UFW firewall
Persistence → systemd service
Host → DigitalOcean $6 VPS
Domain → aureonops.dev
Building the Backend
The core of AUREON is a single main.cpp file.
No router library. No HTTP parsing library.
Raw socket programming.
The server works like this:
// Create socket
SocketType serverSocket = socket(AF_INET, SOCK_STREAM, 0);
// Bind to port 8080
sockaddr_in serverAddr;
serverAddr.sin_family = AF_INET;
serverAddr.sin_port = htons(8080);
serverAddr.sin_addr.s_addr = INADDR_ANY;
bind(serverSocket, (sockaddr*)&serverAddr, sizeof(serverAddr));
listen(serverSocket, 5);
// Accept connections
while (true) {
SocketType clientSocket = accept(serverSocket, nullptr, nullptr);
char buffer[30000] = {0};
recv(clientSocket, buffer, sizeof(buffer), 0);
// Parse request, build response, send it back
}
That's the entire connection model. Accept a request,
handle it, close the connection, repeat.
Cross Platform from Day One
One non-negotiable requirement — it had to compile
on both Windows and Linux.
The solution was clean #ifdef guards:
#ifdef _WIN32
#include <winsock2.h>
#pragma comment(lib, "ws2_32.lib")
#else
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#endif
#ifdef _WIN32
using SocketType = SOCKET;
#else
using SocketType = int;
#endif
Developed on Windows in CLion. Deployed on Ubuntu.
Same codebase. Zero changes.
API Routes
Request routing is done via simple string matching
on the raw HTTP buffer:
if (request.find("GET /api/status") != std::string::npos) {
response =
"HTTP/1.1 200 OK\r\n"
"Content-Type: application/json\r\n"
"Access-Control-Allow-Origin: *\r\n\r\n"
"{\"status\": \"online\", \"engine\": \"C++\"}";
}
Not elegant by framework standards. But completely
transparent. You know exactly what every byte of
that response contains.
File Serving
Static files are served directly from disk:
std::string serveFile(const std::string& path,
const std::string& contentType) {
std::ifstream file(path);
std::stringstream buffer;
buffer << file.rdbuf();
return "HTTP/1.1 200 OK\r\n"
"Content-Type: " + contentType + "\r\n\r\n" +
buffer.str();
}
The frontend lives in a /frontend folder —
index.html, style.css, script.js.
The C++ server reads and serves them on every request.
The First Deployment Disaster 💀
Everything worked on localhost. Time to go live.
I spun up a DigitalOcean Ubuntu droplet, cloned
the repo, built the binary, and ran:
ufw enable
And immediately locked myself out of SSH.
The mistake? I enabled UFW before adding port 22.
UFW's default is deny all incoming — including SSH.
The server was unreachable. Web console timed out.
Complete lockout.
The fix: Destroy the droplet. Start over.
This time with the correct order:
# Allow SSH FIRST — before anything else
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 8080/tcp
# THEN enable
ufw enable
Lesson learned the hard way. UFW order of operations
matters. Always allow SSH before enabling the firewall.
Cross Platform Build Issue
The Linux build hit another wall immediately:
fatal error: winsock2.h: No such file or directory
The CMakeLists.txt was linking ws2_32 unconditionally
— a Windows only library. Linux doesn't have it.
Fix:
if(WIN32)
target_link_libraries(cpp_backend_test ws2_32)
endif()
Three lines. Problem gone. Build succeeded.
systemd — Making It Persistent
A server that dies when you close the terminal
isn't a server. It's a demo.
The fix is a systemd service:
[Unit]
Description=AUREON C++ Backend
After=network.target
[Service]
WorkingDirectory=/root/aureon-cpp-backend
ExecStart=/root/aureon-cpp-backend/server
Restart=always
RestartSec=3
User=root
[Install]
WantedBy=multi-user.target
systemctl enable aureon
systemctl start aureon
The systemd bug that looked like a backend failure
At one point the service was active, but the site returned:
404 - File not found
The binary was running, but it could not find frontend/index.html.
The fix was not in C++ at all. It was systemd:
WorkingDirectory=/root/aureon-cpp-backend
That is a real engineering lesson.
---
### 6. Mention the Cloudflare 521 issue
This is another great struggle section.
Add:
md
The Cloudflare 521 problem
After the domain was connected, Cloudflare returned:
521 Web Server Is Down
The backend was alive. curl http://127.0.0.1:8080 returned the correct HTML.
That narrowed the issue down to the path between Cloudflare, Nginx, and the origin SSL configuration.
The lesson: when debugging production, test each layer separately.
- Is the backend alive locally?
- Is Nginx proxying correctly?
- Is DNS pointing correctly?
- Is SSL mode compatible with the origin?
Debugging checklist I wish I had earlier
# Is the backend alive?
curl http://127.0.0.1:8080
# Is the backend listening?
ss -tulnp | grep 8080
# Is the service running?
systemctl status aureon
# What did the service log?
journalctl -u aureon -n 50 --no-pager
# Is Nginx config valid?
nginx -t
# Is the firewall correct?
ufw status
Now AUREON:
- Starts automatically on boot
- Restarts automatically on crash
- Runs 24/7 without a terminal session
---
## Nginx — The Right Way to Expose a Backend
Running a C++ binary directly on port 80 is
not how production works.
Nginx sits in front as a reverse proxy:
nginx
server {
listen 80;
server_name aureonops.dev;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Benefits:
- Clean port 80/443 — no `:8080` in the URL
- SSL termination handled by Nginx + Cloudflare
- Easy to add rate limiting, caching later
- Industry standard architecture
---
## Cloudflare — Free Enterprise Grade Protection
Pointing the domain through Cloudflare's orange cloud
gave AUREON:
- **Free SSL/TLS** — HTTPS on aureonops.dev
- **Cloudflare edge layer — DNS, proxying, TLS, and CDN capability
- **DDoS protection** — built in, automatic
- **DNS management** — fast, reliable
HTTPS is enabled through Let’s Encrypt on the origin server, with Cloudflare handling the edge layer. — Cloudflare encrypts
all the way to the origin server.
---
## The Final Architecture
User Browser
│
⌄
┌─────────────┐
│ Cloudflare │ < DNS + CDN + DDoS + SSL
└──────┬──────┘
│ HTTPS
┌──────⌄──────┐
│ Nginx │ < Reverse proxy, port 80/443
└──────┬──────┘
│ HTTP
┌──────⌄──────┐
│ AUREON │ < C++20 binary, port 8080
│ C++ Engine │
└─────────────┘
│
DigitalOcean
Ubuntu 24.04
$6/month VPS
---
## The Result
[aureonops.dev](https://aureonops.dev) is live.
A raw C++ binary handling real HTTP requests,
serving a production frontend, secured by Cloudflare,
proxied by Nginx, running 24/7 as a systemd service
on a $6 VPS.
Performance characteristics:
- Binary size: < 500KB
- Memory usage: < 10MB
- Cold start: < 10ms
- Zero runtime dependencies
---
## What I Learned
**1. Low level is not harder — it's more transparent**
Frameworks hide complexity. Raw sockets reveal it.
Both have their place but understanding the low level
makes you a better developer at any level.
**2. Production is a different beast than localhost**
UFW, systemd, Nginx, SSL — none of this exists
on your laptop. The gap between "it works locally"
and "it works in production" is where real
engineering happens.
**3. C++ for web backends is underrated**
Not for every use case. But for performance
critical, low latency, resource constrained
systems — nothing comes close.
**4. The stack matters less than the fundamentals**
Understanding sockets, HTTP, file serving, process
management — these skills transfer to every stack.
---
## What's Next for AUREON
AUREON is evolving into a high performance backend
infrastructure platform:
- Multi-threaded connection handling
- Built in metrics and telemetry
- One command deployment scripts
- Docker container support
- Developer template packages
The goal: make C++ backend deployment accessible
to engineers who care about performance without
the painful setup.
---
## Try It Yourself
The full source code is open source:
**GitHub:** [APO72A/aureon-cpp-backend](https://github.com/APO72A/aureon-cpp-backend)
**Live:** [aureonops.dev](https://aureonops.dev)
If you have questions, drop them in the comments.
Happy to go deep on any part of this. ⚙️
---
*Built with C++ · Deployed on DigitalOcean ·
Secured by Cloudflare*
Top comments (0)