Frequently Asked Questions
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.
Lots! Here's a partial list of the ones most frequently asked about or used:
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 HTTP services (e.g. web sites) to be accessed from outside our network. A partial list of servers that will not work with our system includes:
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:
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:
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 a login name, the name you want us to call you, and a working email address.
Any program that can upload to our system using the FTP protocol should work. Our members have successfully used many popular WYSIWIG editors (e.g. Dreamweaver) to create web pages and upload them to our system. Given the swiftly-changing nature of this kind of software, we'd recommend visiting our Member Forum or doing a general search for the latest information.
In addition to regular FTP, we also offer SFTP (Secure FTP) and scp support should you wish to upload your files under the aegis of strong encryption.
Of course, since we offer ssh-secured shell access, you are equally welcome to use vi as your HTML editing tool if you prefer. (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.
*Must... keep from... snickering.
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 do not provide spam protection per se. As a forwarding server if we discarded spam messages, any "false positives" that were incorrectly flagged as spam would be forever lost. That obviously won't work.
Complicating this, not all of our members are alike. They have a broad difference of opinion about what constitutes spam and/or undesirable messages. Some people provide tech support and need to be able to receive forwarded copies of spam and viruses that most of the rest of us would never want. One size does not fit all!
What we do instead is 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. This blocks most illegitimate messages based on delivery mechanisms, not the context of the message. If you want, you can read all about our Email Acceptance Policy.
Although a fair amount of spam slips through this net, it has been pre-screened in such a way that a client-side junk email filter, such as those offered by most email software, can rely on information about its delivery to be accurate and therefore do an excellent job of filtering the spam according to your specific personal criteria without becoming confused by all kinds of forgeries and maliciously-crafted messages.
Naturally, whatever email server ultimately handles the messages we forward for you may also impose content-based junk email filters.
The net result of this is a highly effective, layered defense that, through its dependence on client software under your control, best meets your specific needs.
We use 64-bit Intel Xeon 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 experimental IPv6 support for HTTP access to member sites hosted here. It can be enabled on a per-site basis from our member interface, but since IPv6 support is not yet ubiquitous on the Internet, it is not yet enabled by default.