How a $3 eBay Hosting Account Taught Me to Run My Own Web Infrastructure

I was outgrowing conventional hosting

By the time I was running multiple domains—some client work, some public-interest projects, some just things I wanted to build to learn—paying for a separate hosting plan per project stopped being realistic. Each new idea meant another signup, another dashboard, another recurring charge, often for a plan sized for one small site when what I actually needed was somewhere to run several small, different things at once: a database here, a PHP app there, an email address for a project that didn't need its own server.

What I actually needed was a place with room to experiment—support for multiple domains, enough resources to run real databases and backend services, and the ability to break something on a Tuesday afternoon and fix it myself instead of opening a support ticket and waiting.

The $3 eBay listing

On April 10, 2025, I bought a hosting account through an eBay listing for $3. I want to be accurate about what that listing said and what I actually got, because the two aren't quite the same thing.

The listing's headline advertised "12 Cores, 24GB RAM" and called the product cloud VPS hosting. Those specs weren't dedicated to my account—they described the larger server the seller was running, shared across all of their hosted customers. My $3 didn't buy 12 dedicated CPU cores or 24GB of dedicated memory, and I don't think it was ever reasonable to read it that way once I understood how the account was actually provisioned. I'm not accusing the seller of anything—reseller hosting sold this way is common, and the account did what a low-cost shared or reseller DirectAdmin account does.

What I actually received was still genuinely useful: DirectAdmin access, support for up to 10 domains, reasonable storage and bandwidth for small projects, working databases, email accounts, and a place to experiment without worrying about breaking someone else's production site. For $3, that was a fair trade, as long as I understood what I was actually looking at.

DirectAdmin was the doorway

I'd used shared hosting before, but always through a simplified interface that hid most of what was actually happening. DirectAdmin didn't hide it. Logging in for the first time, I was looking at the individual pieces that a website is actually made of: domain and subdomain setup, DNS zone records, database creation, PHP version selection per domain, SSL certificate issuance, individual email accounts, file permissions, raw logs, and backup configuration.

Having those pieces visible didn't mean I understood how they connected yet. DirectAdmin will hand you a DNS zone editor whether or not you know what an MX record does. It opened the door; walking through it meant actually learning what each piece was for, usually by changing something and watching what broke.

Learning DNS by breaking and fixing it

DNS was the first thing I actually had to understand end to end, because getting it wrong makes a domain visibly stop working. The practical relationships I had to learn were fairly simple once they clicked, but nobody hands you the plain-English version up front:

• Nameservers tell the rest of the internet which server holds the authoritative DNS records for a domain—get this wrong and nothing else matters, because no other record gets looked up.
• A and AAAA records point a domain or subdomain at a server's IPv4 or IPv6 address—this is what makes "example.com" resolve to an actual machine.
• CNAME records point one name at another name instead of an address, useful for aliasing a subdomain to another host without duplicating an IP record.
• MX records tell other mail servers where to deliver email for a domain—separate from, and easy to confuse with, the records that route web traffic.
• TXT records hold arbitrary text used for verification and policy—this is where SPF and DMARC live, and where domain-ownership verification checks usually look.
• Propagation is the delay between changing a record and every resolver on the internet actually seeing the new value, driven by DNS caching (TTL)—the most common reason a change "isn't working yet" when it actually is.
• SSL certificate validation often depends on DNS being correct first—automated certificate issuance typically checks that a domain resolves to the server requesting the certificate before it will issue one.

None of that is complicated in isolation. What made it click was breaking it—pointing a record at the wrong place, watching a site or an inbox go dark, and tracing back through the chain to find which record was wrong.

Learning OpenLiteSpeed and web-server routing

The account ran on OpenLiteSpeed, and one of the more useful things I learned early was that a control panel is not the web server. DirectAdmin is the interface; OpenLiteSpeed is the software actually listening on the network and deciding what to do with a request. DirectAdmin manages OpenLiteSpeed's configuration through templates and virtual host definitions, but the two are separate layers, and understanding that separation mattered for troubleshooting anything that went wrong below the panel's surface.

The rest came in pieces, not all at once:

• Virtual hosts let one server, on one IP address, serve many different domains—OpenLiteSpeed decides which site to serve based on the hostname in the incoming request.
• Ports 80 and 443 handle ordinary web traffic, HTTP and HTTPS respectively—typically only one listener process can bind to each port, with virtual hosts sharing that listener based on the requested domain.
• PHP applications need the web server to hand off requests to a PHP handler—that communication layer (commonly LSAPI on OpenLiteSpeed) is a separate thing to configure correctly per domain, per PHP version.
• Rewrite rules and document roots determine what file or application actually answers a given URL—get the document root wrong and the domain resolves fine but serves the wrong thing, or nothing.
• Reverse proxies come into play for anything that isn't plain PHP—a Node.js application, for instance, runs its own process on its own port, and the web server has to be configured to forward matching requests to it instead of trying to serve it directly.

I did not understand all of this the first week, or the first month. Most of it arrived the way DNS did—by hitting a wall (a domain that resolved but showed the wrong site, a Node app that worked on its own port but not through the domain) and working backward until I found the layer that was misconfigured.

Email was an entire infrastructure project

Creating an email inbox in DirectAdmin takes about ten seconds. Getting that inbox to reliably send mail that doesn't land in spam is a much bigger project, and it's the part nobody mentions when they talk about "just adding an email account."

Underneath a mailbox, DirectAdmin relies on Exim ↗ as the mail transfer agent—the software actually responsible for sending and routing mail—and Dovecot for handling mailbox access, the part that lets an email client actually log in and read messages. Getting mail to deliver reliably meant learning how a handful of authentication mechanisms work together, in plain terms:

• SPF (Sender Policy Framework) is a DNS record listing which servers are allowed to send mail for a domain—receiving servers check it to catch obvious spoofing.
• DKIM (DomainKeys Identified Mail) cryptographically signs outgoing mail so the receiving server can verify it wasn't altered in transit and actually came from where it claims to.
• DMARC tells receiving servers what to do when a message fails SPF or DKIM—and gives the domain owner a place to receive reports about mail claiming to be from their domain.

Beyond those three records, deliverability also depends on things like reverse DNS matching the server's identity, the HELO/EHLO greeting a mail server presents on connection, TLS on the mail connection itself, and the sending server's general reputation. According to DirectAdmin's own documentation ↗, getting all of these correct is treated as the baseline for reliable delivery, not an advanced option—and tools like mail-tester-style deliverability checks became a normal part of how I verified a domain's mail setup before trusting it. I'm not publishing the specific DNS values, selectors, or server identifiers I actually use—those are configuration details, not something a reader needs to see the concept explained.

The backend kept expanding

Once the domain, DNS, and email pieces were solid, the actual applications became the ongoing work. Running real projects on the account meant learning to operate PHP applications across different versions, MariaDB/MySQL databases, and eventually Node.js services that didn't fit the traditional PHP-and-database model at all.

That meant learning process management for anything long-running, cron jobs for scheduled tasks that couldn't depend on a visitor triggering them, file and directory permissions and ownership (and the specific ways getting those wrong breaks an application silently), how to read log files when something failed instead of guessing, when a service needed to be restarted versus reconfigured, and how environment-specific configuration is supposed to be kept separate from application code. Server administration stopped being a separate skill from building the application—it became part of making the application actually reliable.

Backups, monitoring, and security

Having a backup feature in a control panel and having a system you can actually recover are two different things. DirectAdmin's backup tooling supports scheduled backups on a cron-based schedule, and can write them locally or push them to a remote destination like FTP storage, according to DirectAdmin's own documentation ↗. Turning that on was the easy part. Actually trusting it meant periodically restoring a backup somewhere and confirming it worked, not just assuming a scheduled job that "completed successfully" would actually bring a site back if I needed it to.

Beyond backups, the ongoing responsibilities I learned to treat as routine rather than optional included: monitoring disk usage before it became an outage, keeping software and PHP versions patched, setting firewall rules instead of leaving every port reachable, protecting login access against brute-force attempts, running periodic malware scans, checking that services were actually healthy rather than just "running," applying least-privilege access instead of using one account for everything, and actually reading logs instead of only reaching for them after something had already gone wrong. None of this makes a server secure once and done—it's a maintenance habit, not a checkbox, and I don't think any server, including mine, is ever perfectly secure. It's a question of reducing risk and staying attentive, not eliminating it.

Building web apps pushed me deeper into Linux

I did not originally set out to become a Linux server administrator. I wanted to build things—websites, web applications, APIs, databases, automation tools, and services that could keep running after I closed my laptop.

DirectAdmin helped me manage ordinary hosting tasks, but the control panel could only take me so far. As my projects became more ambitious, I needed to understand the operating system underneath it. A static website can be uploaded and served without much thought. A real web application introduces an entirely different set of questions:

• How does a Node.js application stay running after the request that started it ends?
• How does OpenLiteSpeed route a request to it—what does an OpenLiteSpeed reverse proxy actually do?
• Which ports should be public, and which should stay internal?
• Which user owns the application's files, and why can one process read a file while another gets a permission error?
• Where do the logs go when an application fails?
• How do environment variables and secrets reach an application safely?
• How do scheduled jobs run without someone manually starting them?
• How do I update one service without breaking every other site on the same box?
• How do I recover when a deployment fails halfway through?

Those questions pushed me past clicking through a hosting panel and into the command line over SSH, because that's where the actual answers lived. The $3 hosting account introduced me to DirectAdmin. The applications I wanted to build pushed me underneath DirectAdmin and into Linux itself.

Learning Linux for web development, in my case, meant learning: files, directories, ownership, and permissions; users, groups, and process isolation; packages and software dependencies; services and process management; ports, listeners, and network connections; environment configuration; logs and error tracing; cron jobs and scheduled automation; web-server routing and reverse proxies; PHP and Node.js runtimes; database services; disk, memory, and CPU usage; software updates and security patches; and backups, restoration, and recovery.

I learned most of it the way I learn development generally: build something, test it, discover what failed, read the logs, research the specific piece that broke, and repair it. This was self-taught Linux administration in the most literal sense—no course, just real deployments that needed to keep working. Sometimes the problem was my code. Sometimes it was a file permission, a missing package, a stopped service, a DNS record, a firewall rule, or a web-server configuration. Learning to tell the difference changed how I approached software development generally, not just server work.

The control panel showed me the pieces. Deploying web applications for real—ones with a backend, a database, and a process that has to stay alive—forced me to understand how those pieces actually worked together as backend deployment and web application infrastructure, not just as items in a dashboard.

Today, when I build an application, I'm not thinking only about the interface or the code. I'm also thinking about how it will be deployed, how its process will stay alive, where its data will live, how it will send email, how it will be monitored, how it will be backed up, and how it can recover from failure. That's the level Linux VPS administration pushed me toward—not because I was chasing a certificate or memorizing terminal commands, but because I wanted to build useful systems and keep them working.

From a hosted account to my own VPS

The $3 account was the classroom, not the destination. As my own projects and skills grew past what a shared reseller account could reasonably support, I moved to administering my own VPS, running AlmaLinux with DirectAdmin and OpenLiteSpeed—the same software stack I'd learned on, but now with full control over the underlying server instead of a slice of someone else's.

The progression, in order, was: financial constraint → a $3 multi-domain account → DirectAdmin → Linux administration → custom web applications → an independently operated VPS. I'm not publishing the current provider, location, IP address, or exact capacity here—those details don't change the point of the article, and there's no reason to put them in a public post.

My VPS later became more than a place to host websites. After my laptops were stolen, Termux and SSH let me reach that server from an Android phone. Working that way pushed me deeper into the command line and finally made Git and GitHub feel like an operating system for my projects instead of somewhere to upload code—more on that in how I learned to build from Android.

What $3 bought—and what it taught me

What I'd tell another builder

• Cheap hosting can be a genuinely useful learning environment—treat it as one, not as production infrastructure for anything that matters.
• Don't assume a marketplace listing's headline specs are dedicated to your account. Ask, or verify directly, what you're actually provisioned.
• Check storage, CPU, memory, bandwidth, and domain limits before you build something that depends on them.
• Keep independent backups you control, separate from whatever the host provides.
• Don't start with sensitive client or customer data on a low-cost, unverified account.
• Expect limited support—cheap accounts usually mean you're your own first line of troubleshooting.
• Learn on disposable or recoverable projects, not on something you can't afford to lose.
• Move to better-controlled infrastructure once your projects actually justify the cost and responsibility.
• Owning a VPS means accepting maintenance and security as your job now, not the host's.

Conclusion

The $3 didn't buy me a 12-core VPS. It bought me access to a system I didn't yet understand, described in a way that oversold what my particular account actually had. Learning that system—DNS, the web server, mail authentication, the database and backend layer, backups, and basic security discipline—changed what I was capable of building and operating on my own.

The account did more than lower my hosting costs. It pushed me into Linux, backend development, and infrastructure—the parts of building software that determine whether an application merely works once or keeps working in the real world. That's the direct line between one cheap eBay listing and being able to build, deploy, migrate, troubleshoot, and run websites and backend systems today without depending on someone else to hold the parts I don't understand.