Yes, absolutely! You can run PHP, python, ruby, perl, lisp and tcl applications on our system, as well as many others.
We have custom integration for PHP, as well as support for using FastCGI, SCGI, and HTTP to speak to an application server written in the language of your choice, like Django, Ruby on Rails, or Node.JS.
CGI has fallen out of favor due to its drawbacks; all of those alternatives didn't emerge because it was so great. However, it still fills a need and works fine here; you can simply put a CGI script in your web space with a .cgi extension, and mark it executable.
We update our support for programming languages very frequently. Check our home page for links to current example configurations.
SSI (server-side includes) can be used by naming your files with a .shtml extension.
Full MySQL support is available. We give you your own private MySQL process and full administrator
privileges; there's no need to worry about other users trampling on your databases or trying to shoehorn several applications into a single database.
To help you manage your process remotely without having to install and maintain extra software, we provide a private installation of phpMyAdmin that can be used to access hosted processes easily.
We also support a number of common database libraries in both PHP and CGI applications, including SQLite, db4 and gdbm.
Some server types also allow configuring processes like memcached, Mongo, and Redis.
We support modern/secure TLS using certificates issued by the authority of your choice. You are welcome to generate and use your own key and obtain certificates for aliases in any domain name you own, or you can have us do it for you for a small fee, or you can use streamlined tools we provide that work with the Let's Encrypt project to secure your site.
TLS on our system is implemented using the SNI (Server Name Indication) extension of
TLS. This has widespread support, but somewhere out there on the Internet, some ridiculously obsolete browser or ancient device with outdated firmware can't handle it. If you have a requirement to support old, known-insecure versions of SSL, we cannot meet that requirement.
Our implementation of TLS has not been audited for and we do not support its use for the following:
HIPAA compliance for sensitive medical information. (There's paperwork. Lots of it. You need a specialized — and very expensive — provider who can help prepare your compliance documents.)
Yes, almost any directive that can be placed in an Apache .htaccess file will work on our system. The most significant ones that will not work are those that perform access control based on IP address; due to our network architecture, IP blocking is performed before requests reach .htaccess and must be configured separately.
The most common location for .htaccess files is /home/public. By default, no .htaccess file exists, so if you want one you will have to create it yourself.
To an extent, yes. However, we only allow HTTPS (and legacy HTTP) services (e.g., websites) to be accessed from outside our network. A partial list of servers that will not work with our system includes:
Live streaming
Non-web-based MUD and gaming servers (including Minecraft)
Voice/video chat servers not based on WebRTC
email servers (SMTP, POP, IMAP)
anonymous FTP servers
IRC bots and servers (though many web-based chat programs do work)
The bottom line is that if a service speaks the HTTP protocol on TCP ports 80 or 443, it is likely to work. If it doesn't, it definitely will not.
We have our own custom control panel that is as unique as the rest of our service. While it is in no danger of winning any awards for its great beauty, it does allow you to control most aspects of our service without resorting to complicated configuration files. The major benefits of this custom environment are:
It matches the services we offer very closely.
If you need help with it, it's a safe bet you aren't going to stump us, since we wrote it.
When people write to us and say "you should add (feature) to the control panel" we can occasionally write back later that day and say "Good idea, try it out."
There's no "demo" of our control panel, but you can create a membership and kick the real thing around for yourself. Naturally, doing so is completely free. To get a basic idea, all you need to provide is your name, a login name, and a working email address. (We promise not to spam you.)
To get a better idea, we recommend that you create an account, which will require your basic information (real name, address, etc.), but don't worry, our privacy policy has your back. No payment information is needed to check out the control panel. So please try creating an account; you might be surprised by what happens next!
The most popular and successful tools used for uploading content to our site are those based on secure, modern technologies like SCP, and SFTP. This includes most web design programs and most file transfer utilities.
For managing site content directly, we also provide SSH access to the command line. This includes a full suite of preinstalled utilities like rsync, git, and unison that can be used to transfer or synchronize content between your local system and a site hosted on our service. But, if you prefer, you can also hand-code your entire site in vi (an elegant editor for a more... civilized... age). Or emacs, pico, nano, and others.
Erm, this is embarrassing. We used to have a list of things here that were known not to work on our system. But now they all work. So, uh, there's not much to see here right now.
Our system is for web sites only. So most of the inquiries we get about things that won't work are things that aren't web-based.
We have a corporate policy that we do not offer services that consume IP address space on a per-site or per-user basis. The most common example of this is when a web site is assigned one (or more) static IP addresses, but it also applies to anonymous FTP sites and some other types of hosted services.
Assigning static IP addresses on a per-site basis is a practice that has devastated the Internet address space, so we don't participate in it. Tens of thousands of IP addresses can be assigned to a single rack of equipment in a datacenter somewhere, but there is a shortage of IP address space. That's not the right way to do things.
We regard this as an "Internet environmental" issue, and it's one about which we're prepared to be a little extremist. Basically, we believe that it's wrong for us to do it, so we don't do it. Not everyone agrees with us, and we definitely do lose business because of this position.
For standards-compliant web hosting (HTTP/1.1), there is no need to assign a static IP address, and no supported browser remains available that requires this. Static IP addresses also severely limit our ability to reroute around equipment that has problems or is being maintained, and even makes it tougher for you to benefit from our load balancing technology.
The most common reason people request a static IP address is to point external DNS at a site hosted with us. As part of our hosting service, we provide our own special DNS records for each site that you can link to external DNS using the CNAME capability that work even better than static IPs. These records preserve full fault tolerance and load balancing.
Yes. Our NearlyFreeSpeech.NET DNS service allows unlimited subdomains under a single domain name at no additional charge.
Please be aware, however, that we do not use the subdomain-is-subdirectory hack (unfortunately) made popular by a certain brand of web hosting control panel software. You can use our service to create multiple independent sites and then assign or remove names from one or more NearlyFreeSpeech.NET DNS domains at your discretion. There is no connection between a site and a domain name or subdomain other than what you create, and there is no correlation at all between subdirectories of a site and subdomains of a domain.
Subdomains can be associated with sites we host by adding them as aliases. If you're a member, see this member FAQ entry for more information.
Our hosting platform uses a network of distributed, fault-tolerant,
load-balancing shared servers. Sites are automatically distributed across the servers to make the best use of resources based on the popularity of the site and the capacity of the server. As a result, there is no need to fear having busy or CPU intensive sites on the same server slow you down; our system will re-balance them automatically.
On our system, a gigabyte is 1,073,741,824 bytes. Hard drive manufacturers would have you believe that it's 1,000,000,000 bytes, but we don't sell hard drives.
Technically 1,073,741,824 bytes is a gibibyte, but we have a hard time calling it that without a childish urge to snicker, and nobody likes a snickerer. If you want to be strictly accurate, the hard drive manufacturers are right, and we bill storage and bandwidth based on gibibytes* and mebibytes* (1,048,576 bytes), not gigabytes and megabytes.
Someday we'll grow up about this, but that day has not yet arrived. We are moderately more mature when it comes to the abbreviations, and we try to use MiB and GiB to represent base-2 prefixes correctly wherever possible.
A MySQL process can contain as many databases as you wish. You can also create multiple MySQL processes if you wish. Doing so will cost more than placing all your databases in a single process, but will increase the available resources.
For those with particularly demanding database needs, we also have hosted dedicated MySQL offerings including reserved resources and advanced features like thread pools.
We use a layered approach to spam prevention on our email forwarding service.
First, we outright block messages from known malicious senders, like compromised servers.
Second, we enforce strict restrictions on the email servers that attempt to send email through our forwarding systems. These restrictions are no problem for legitimate email servers (they should all be passed by default on a properly configured system), but they represent a tough barrier for the sort of compromised, virus-infected servers that send most of the world's spam. These restrictions block most illegitimate messages based on delivery mechanisms, not the content of the message. Our public site has more information about our Email Acceptance Policy. This step includes greylisting.
Third, we do some very minimal content-based spam filtering to catch the worst of the worst that gets past the rest of the checks. If a message fails this filtering, it goes to your domain's email quarantine, accessible through our member interface. The level is set high enough to produce vanishingly few false positives but a fairly high rate of false negatives. In other words, you shouldn't see any legitimate messages get blocked by this filter, but you will see spam slip through.
This system is designed to balance two conflicting goals:
Keep as much control as possible over determining whether a message is spam and what to do about that in the hands of the recipient.
Keep other providers from blacklisting us due to the messages we forward.
If you have us forward messages to a third-party service, which most people do, whatever spam filtering they use will also apply. And, finally, you can (and should) use tools in your email client to make the final determination. The rest of these steps are designed to give those tools their best chance to work.
This approach provides a highly effective, layered defense against spam.
We use 64-bit AMD Epyc based servers with ECC RAM, and all member sites run on FreeBSD. The specifics of our hardware evolve quite rapidly, and we don't throw away stuff that still works just because something newer came along. Our load-balancing algorithms are sophisticated enough to handle a heterogeneous environment.
Yes. NearlyFreeSpeech.NET strongly supports the migration of the Internet to IPv6. Most of our own sites, including www.nearlyfreespeech.net and members.nearlyfreespeech.net are IPv6 enabled. We also support IPv6 for ssh access to member sites.
We also offer IPv6 support for HTTP/HTTPS access to member sites hosted here. It is enabled by default on newly-created sites. For existing sites, it can be enabled on a per-site basis from our member interface.
