I Built and Deployed a Production Web Backend in Raw C++20

APO72A — Mon, 18 May 2026 07:37:47 +0000

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:

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*

DEV Community: APO72A