It works great (and there's a ton of tutorials) for setting up logs with things like Logstash or Fluentd. It also works for other data-driven application, but the target audience of this article probably won't be developing something like this any time soon.

Self HostedMailpile is a modern web-mail you run on your own computer.You can host your install of mailpile on your laptop, desktop, Raspberry PI or a server in the cloud. Or put it on a USB stick and carry it in your pocket. It's your choice.

What Mailpile is I don't know, but that's what the website says. Sounds like it's at least worth checking out.

Most Linux dists will install Apache with PHP running and MySQL set up. Well most serious ones anyway.

Just stuff yer junk into htdocs/, done deal.

It was far more fun to compile the whole shebang together, although somewhat daunting, order certainly mattered among other things.

A tiny tip for home users. If you run your homemade server on a network where they don't allow servers, your regular home internet connection for example, just run your server on port 90, they will miss that when they scan.

The mailpile to-do list suggests they are working on implementing IMAP ( ) and POP3 ( ) functionality, as well as some sort of SMTP relay. So it looks like it's going to take on some fairly mailserver-like functions. Definitely one to keep an eye on.

Another one worth a look: ownCloud. It gives you Dropbox/Google Calendar/Google Contacts like functionality on your own box.

Or seafile, I installed seafile and it's pretty nifty, it offers client side encryption too. I'm wouldn't dump all my confidential information into a seafile instance just yet, put it's made some promising first steps into becoming a real secure contender.

Also along side spam assassin and postfix, you're probably going to want to install something like clamav/amavisd:

All well and good.. but this is all so 2000s.. today I see a lot more interest in running applications directly on cloud providers to leverage their shared infrastructure. Next time, maybe an introduction to running your website on OpenShift or AWS instead of directly on your own box. (or you should write articles about redundancy, fault tolerance and backups because I know that is a vitally important task to running any web server)

I was a fan of Urchin, which was self hosted. For those that don´t know, Urchin was purchased by Google and that is now Google Analytics, like all companies and products Google buys, they eventually killed Urchin completely, the self hosted Urchin software... And Urchin was a paid product, but Google decided to kill that in favor of a free hosted in Google, that should tell you something about how bad Google WANTS your data. Paid = Money, Free = ????. Google does not want you to host anything on your side even if you pay for it. They want your data which means your data has a huge value in $$$ for this companies, they would prefer to have your data rather than you having it and paying them for using the software. This should make some people wonder what they actually do with your data that is has so much value for them.

So I think Piwik is a great alternative to Google Analytics, its the most robust alternative so far.

This articles are great, in particular because they show people how to install and run their own data as opposed to all this external services. Once you host your own data, yes it may be more work, but you are going to love it since that customization and control is far superior than having software in servers you can´t control.

Also, one huge plus of running things in your server, in particular Piwik, just to name one example, is speed. When Google Analytics or an external party server runs slow, so will your website that will be stuck waiting for all this external scripts to load. I saw it happening so many times in so many websites, in particular those that run ads, when this external parties are not working, the whole website comes to a crawl. Running the stats locally does not only let you collect real data from the server side, something you can´t with Javascript, but its also native fast as it runs all in your local server.

In a world where everything is moving to the cloud and external services, its nice to see some people still appreciate doing and running things on their own setups.

All well and good.. but this is all so 2000s.. today I see a lot more interest in running applications directly on cloud providers to leverage their shared infrastructure. Next time, maybe an introduction to running your website on OpenShift or AWS instead of directly on your own box. (or you should write articles about redundancy, fault tolerance and backups because I know that is a vitally important task to running any web server)

AWS and so those providers don´t give you any redundancy or HA out of the box. You still need to setup all that on your own, so this article is perfectly fine since it also applies to any cloud server which is nothing more than a virtual machine. AWS is a Xen machine, nothing more. It does not magically scale your app or software. If that hardware where your AWS instance has problems you are down, if you don´t happen to run multiple AWS instances in separated places, and one datacenter goes down, you are down again.

Its nothing that did not existed 10 years back. They just allow you to easily launch new virtual machines, but all the configurations that are explained here still apply today and tomorrow, since its on your side to manage the servers.

It is a self-hosted groupware solution (so contacts and calendars in addition to email) which supports Activesync as well as IMAP/CalDAV/CardDAV, which means native syncing with iOS, OSX, Android, Windows Phone, Windows 8+ AND Outlook 2013. I don't know of anything else that can do that.

It does require IMAP access to work (so you'll have to set up your own sendmail/postfix and dovecot, which can be a huge pain) and the web UI is a bit crap, but the whole point is that you won't have to use it anyways

AWS and so those providers don´t give you any redundancy or HA out of the box. You still need to setup all that on your own, so this article is perfectly fine since it also applies to any cloud server which is nothing more than a virtual machine. AWS is a Xen machine, nothing more. It does not magically scale your app or software. If that hardware where your AWS instance has problems you are down, if you don´t happen to run multiple AWS instances in separated places, and one datacenter goes down, you are down again.

I agree out of the box they don't provide anything. But there are templates and other software such as System Center than can do a lot of the work for you. At least in terms of getting you started on the right path, but obviously customization might be needed. But once that's done it's as easy as launching any other instance.

I'll say upfront I haven't had the chance to read the entire 9 part series.

I read the first ones and the angle seemed to be "let's play with the idea of self-hosting your online presence on your own hardware and infrastructure". That's something that takes a lot of effort, but like all DIY projects, it can be great fun and teach you a lot in the process.

But this wrapup reads a lot more like "now that we've (gleefully) learned so much, we're ready to run an actual server, and (excitedly) install a bunch of random stuff on it". That doesn't sound like good advice.

With Wordpress having a FAQ on how to react to your site being hacked, I'm not sure getting people to self-host their own Wordpress blog is really the best advice. There's a big difference between learning how these things are done, and encouraging people to go on and do them themselves on public facing servers.

Maybe I missed the part in the series where you warn your readers that it is a really bad idea to self-host anything even remotely popular unless you're committed to it.

The internet is a hostile place. As a software developer, I used to self-host source control for personal projects. But as soon as I tried opening the SSH port to the internet at large, I had to deal with thousands of daily random login attempts bogging down my puny ARM server. It's a rookie mistake, switching the port to something else "fixed" it. I wasn't hacked, no login ever came through, maybe I overreacted. But I really don't want to be bothered having a weekly schedule to make sure SSH is up to date. So a hosted service it is. Unsavory as it is to hand my unencrypted source-code to a third-party (about as unsavory as doing it with email), self-hosting anything is a responsibility not to be taken lightly.

Another one worth a look: ownCloud. It gives you Dropbox/Google Calendar/Google Contacts like functionality on your own box.

This doesn't appear to have iOS and Android clients so it would be no go for most people these days.

I've run my own web and email servers for several years and I wanted to have something like that but in the end decided that running my own server was too much time and trouble. The number of attacks was growing exponentially over the years. What kruzes said above my post. I just don't want to deal with all the security issues. It's too much.

Another one worth a look: ownCloud. It gives you Dropbox/Google Calendar/Google Contacts like functionality on your own box.

Or seafile, I installed seafile and it's pretty nifty, it offers client side encryption too. I'm wouldn't dump all my confidential information into a seafile instance just yet, put it's made some promising first steps into becoming a real secure contender.

Also along side spam assassin and postfix, you're probably going to want to install something like clamav/amavisd:

I reckon clamAV and spam assassin working together bounce around 90% of the spam and Nigerian princes offering my clients refunds inside zip files.

I also picked Seafile and I'm glad I did. It runs as a daemon and therefore gives you similar performance to Dropbox (and I installed it on a Raspberry Pi).

Owncloud doesn't come close to that. As it's written in PHP, you can only setup a cron and you'll have to wait for your files to be synced over your network. The web interface looks unfinished, and it's just too slow.

And I'd like to reply to the last few posts regarding the security implications of hosting services like these on your own hardware. If WordPress has some sort of security issue, what exactly makes you think that HostMonster or AWS is going to fix it for you? Or any service for that matter. Shared or virtual servers are just that. You pay for bare metal (or nearly so) hardware that you configure and run to your liking. There is nothing magical about installing an app on your hosted server that makes it inherently more secure than on your own metal. I will grant that the mail end of it is probably administered by a professional, but that's about as far as it goes. If you think that just because you're on AWS or some other service that you're un-hackable, or that some friendly sysadmin will warn you when your site has been compromised you're simply putting your head in the sand.

The mailpile to-do list suggests they are working on implementing IMAP ( ) and POP3 ( ) functionality, as well as some sort of SMTP relay. So it looks like it's going to take on some fairly mailserver-like functions. Definitely one to keep an eye on.

That is correct—I made sure to actually talk with the Mailpile guys for a while, too. Their goal with the project is indeed to be be a full-fledged self hosted email solution.

kruzes wrote:

But this wrapup reads a lot more like "now that we've (gleefully) learned so much, we're ready to run an actual server, and (excitedly) install a bunch of random stuff on it". That doesn't sound like good advice.

I'd recommend you at least glance at the entire series; that's not quite the intent, any more than learning how to build a bookcase in your garage workshop and finding out that you enjoy making bookcases means you're ready to become a mass-market bookcase seller.

Thanks for all your effort on the series. I have been wanting to do some of these projects but they aren't quite interesting enough to put that much effort into. However, now I have enough documentation in a convenient place to figure out how to get the few things I want functional.

Most Linux dists will install Apache with PHP running and MySQL set up. Well most serious ones anyway.

Just stuff yer junk into htdocs/, done deal.

It was far more fun to compile the whole shebang together, although somewhat daunting, order certainly mattered among other things.

A tiny tip for home users. If you run your homemade server on a network where they don't allow servers, your regular home internet connection for example, just run your server on port 90, they will miss that when they scan.

I tend to agree with going "old school" (apache and PHP), mostly because there are a lot more resources out there for help. PHP code is everywhere. Thus isn't to say the Rolls Royce approach the author used is a bad idea. It us just a matter of how much effort you want to put it the project.

But this wrapup reads a lot more like "now that we've (gleefully) learned so much, we're ready to run an actual server, and (excitedly) install a bunch of random stuff on it". That doesn't sound like good advice.

It gets really old to see the nanny-commenting over and over. It's dangerous to self-host? Noooooo...reallly? Next you'll tell me it is dangerous to rock climb instead of doing it an indoor gym, or that I should hire a cook to do all my meals because my stove is capable of burning me.

This is an enthusiast site. People here conduct themselves accordingly. Lee's series is exactly the kind of content that is a) appropriate and b) desperately needed on Ars. Bravo Lee, keep it coming!

I think there's a real gap in the market for someone to take some combination of the various open source platforms mentioned both in the article, and in the thread comments, and build a sort of "self hosted Google Apps in a can", ideally with an Amazon AWS deployable image, but also with a fairly easy install for the more traditional type of webhost.

Another one worth a look: ownCloud. It gives you Dropbox/Google Calendar/Google Contacts like functionality on your own box.

Or seafile, I installed seafile and it's pretty nifty, it offers client side encryption too. I'm wouldn't dump all my confidential information into a seafile instance just yet, put it's made some promising first steps into becoming a real secure contender.

Also along side spam assassin and postfix, you're probably going to want to install something like clamav/amavisd:

I reckon clamAV and spam assassin working together bounce around 90% of the spam and Nigerian princes offering my clients refunds inside zip files.

I also picked Seafile and I'm glad I did. It runs as a daemon and therefore gives you similar performance to Dropbox (and I installed it on a Raspberry Pi).

Owncloud doesn't come close to that. As it's written in PHP, you can only setup a cron and you'll have to wait for your files to be synced over your network. The web interface looks unfinished, and it's just too slow.

Does not owncloud have native clients that handle the synchronization automatically? Asking the server to do it is a strange approach

I'd recommend you at least glance at the entire series; that's not quite the intent, any more than learning how to build a bookcase in your garage workshop and finding out that you enjoy making bookcases means you're ready to become a mass-market bookcase seller.

Nobody's garage-built bookcase ever sent out 30,000 messages pretending to be from Bank of America in one night.

It gets really old to see the nanny-commenting over and over. It's dangerous to self-host? Noooooo...reallly? Next you'll tell me it is dangerous to rock climb instead of doing it an indoor gym, or that I should hire a cook to do all my meals because my stove is capable of burning me.

The "nanny commenting" is because unlike your stove, your self-hosted stuff probably won't burn you. But it will burn thousands or tens of thousands of people around you the minute you drop your guard or miss a patch update. And if you assume "they won't find my little server" then you have already failed.

Personal responsibility and commitment cannot be over-emphasized in these types of articles.

Personal responsibility and commitment cannot be over-emphasized in these types of articles.

I agree—a neglected server is likely to be a compromised server. But you can break attackers down into two buckets:

1) Casual, unskilled, and/or script-based. These are very easy to protect against using very basic measures like not allowing root logon via ssh, exposing only required services to the Internet, keeping your installed web-facing applications and their components up to day, and performing basic log auditing. We're using some pretty mature technology and there aren't zero-day vulnerabilities falling out of the sky with stuff like ssh (not to say that it doesn't happen, though).

2) Skilled and targeted attackers. These are essentially impossible to protect against and nothing you can do will keep them out if they decide to poke at you. You're also not likely to be a target.

Keeping the guys in the first group out is extremely easy if you're running a simple non-dynamic web site, and becomes more difficult as you add more pieces; the biggest security holes in anything are often not in core apps like WordPress, but rather in popular plugins to core apps. The more stuff you add, the more you need to keep track of and update. Still, it's not difficult to keep yourself safe from the first group.

There's nothing you can do to protect yourself from the second group. Don't even try. Doesn't matter if you're an individual hosting out of your closet or a Fortune 50 company with hundreds of IT security folks running in your own secure data center.

This is great, and much needed. Personally, I like the uber power and control a CLI provides, and this totally makes that available. A GUI for anything is convenient, but pretty much every day I get angry at some piece of software with a GUI that is acting up. A CLI clears all that junk up.

...a personal story: I made my first VPN attempt with a Cisco ASA 5500 without realizing the complexity of this beast. To simply point and click to get it working was a joke; if I could even determine what I was doing in the first place. Thankfully, I paid for 1 year of tech support (I think it is called SmartNet). They saved my butt on this project. I noticed that every time they shadowed me, they ALWAYS used Putty to access the CLI. I mean ALWAYS. They FLEW through commands. It was amazing to watch!

My young childhood years were in the 80s and I grew up on DOS with my Tandy 1000 ex. When Windows 95 was rolled out years later, I felt threatened. Something just didn't settle right. I kept asking the question: "Why would I use all those resources, just to be able to point and click?"

Now that I am raising a family of my own, it is difficult to find the time to learn all the *nix commands, but it is still a lifetime goal of mine.

Thanks again for breaking all this web stuff down for us Lee. You are clearly gifted in doing what you do. I would LOVE to see some more topics like this!