We support two canonical name redirection settings:
off - Our system attempts to avoid the use of a site's canonical name. Redirects issued by the network will use the hostname presented in the HTTP Host: header. From an application standpoint this means that the HTTP_HOST variable will be copied to the SERVER_NAME variable for each request. This setting is particularly suited to sites that vary their content based on which alias is used, such as WordPress multi-site hosting, or if you want to use our per-alias document root feature to host multiple websites using only one site on our system.
on - If anybody accesses your site using an alias other than its canonical name, will automatically, transparently get a "301 Moved Permanently" redirect to the correct name. This setting is particularly appropriate for sites with one correct name, but a number of other aliases that the site owner also wishes to accept.
Your site's canonical name and type settings are visible in the "Config Information" box on the Site Information page for that site. To make changes to your site's canonical name or type settings, use the "Edit" button on the "Canonical URL" line.
If you are running software on your site that lets you designate the official URL for the site (such as WordPress), you'll need to update that information before you enable canonical name redirection to a name that is different from what your software is expecting. If you don't, your software and our system will get into a slap fight over what name is correct, and all visitors to your site will get is a "too many redirects" error.
If that happens, switch the canonical type back to "off" to let your site load and regain access to your software's administration area. (To continue with the WordPress example, the "blog URI" or "WordPress address (URL)" is the software setting in question.)
For more information about canonical names, see this FAQ entry.
(The "on" setting used to be "hard," so if you see any references to "hard canonical," it means enabling canonical name redirection. We also used to have a "soft" setting, which some old sites still have. It's useless and if you see it, you should get rid of it!)
By default, you must create an index file for each directory that you create. This is a security precaution for novice webmasters to protect them from unintentionally exposing files they did not intend to publish.
The index file can have any one of several names:
index.html
index.shtml
index.php
index.htm
default.htm
index.cgi
index.pl
(If more than one of these files exists, the server will use the highest one on the list. These names are case-sensitive. E.g. INDEX.HTML and Index.html will not work.)
If you want the web server to display a list of files in a directory, you add the following line to your .htaccess file for that directory:
Options +Indexes
Note that this directive applies to the directory containing its .htaccess file as well as any and all subdirectories.
Create the forwarding site. If you are going to forward to www.example.com or your-site.some-other-web-host.com, try to give it a short name like examplefwd.
Set up the name you want to forward from as an alias of the examplefwd site.
Create a one-line plain text file on your local computer called htaccess.txt containing the following (replacing www.example.com with the name of the site you want to forward to):
Upload this htaccess.txt file to your examplefwd site hosted here as a text file.
Rename the file from htaccess.txt to .htaccess. (That's "htaccess" with a period in front.)
This approach works for all sorts of URLs, not just the main site. For example, if you use this technique to forward members.example.com visitors to www.example.com/members/ and someone visits http://members.example.com/page.html they will be forwarded to http://www.example.com/members/page.html.
Please note if the target site is hosted here and you merely want to redirect alternative names, setting a hard canonical name is usually faster, easier, and cheaper than this approach. This approach is better suited when the redirection involves two hosts or path manipulation at either or both ends.
The syntax for mod_rewrite rules can be tricky and hard to get just right, especially as they get more complex. The rewrite log can help debug RewriteRules. However, as soon as you debug your rules, it's very important to turn it off.
Because a single rewrite rule can produce several lines of output, the rewrite engine obtains a lock on the rewrite log for each access. This means your site can only process one access at a time, which is a horrible performance penalty.
Worse than that, we have seen Apache occasionally lose this lock if an in-progress request dies during rewrite processing (for example due to a closed connection), which will cause all requests for your site to stall indefinitely until the server won't accept any more.
For these reasons, you absolutely should not run the rewrite log on a production site, or for any longer than absolutely necessary to debug your rewrite rules.
NearlyFreeSpeech.NET provides a basic error page in response to most common types of site errors. Sometimes, you may wish to override these pages and provide your own error messages that fit your site style or provide additional information. In order to do this, add the following line to the .htaccess file in your public directory (you'll need to create this plain-text file first if you don't have one):
ErrorDocument 404 /err404.html
Where 404 is the number of the error you wish to catch and err404.html is the name of the file you want displayed when an error occurs. You may use a PHP or CGI script for an ErrorDocument, but be careful not to use absolute paths to specify the name of your ErrorDocument.
Here are the most common errors:
401 Authorization Required
Indicates that a username and password are required but were not provided or were incorrect too many times.
403 Forbidden
Indicates that security restrictions prevent the requested page from being returned. This is the error returned for brand new sites, because our security prohibits directory indexing without an explicit index file.
404 Not Found
Indicates that the requested page or object was not found, either due to a typo or a broken link.
500 Internal Server Error
Usually indicates that a CGI script encountered an error.
Due to the design of our network, you typically cannot use an ErrorDocument to catch a 503 Service Unavailable error. Such errors do not routinely occur except during system maintenance. They may also occur during some types of partial service interruptions, or if you have a custom server type with improperly-configured daemons or proxies.
It's the name you would use when someone asks you for the address of your web site; the "official" name. This would typically be something like www.example.com, and must be one of the aliases that is associated with your site (this can include the default alias ending in .nfshost.com).
The default canonical name of each site is its nfshost.com alias. If your site's shortname is example, then its default canonical name is example.nfshost.com.
Having a canonical name is especially important when you want to have a bunch of alternative names for the same site. For example, if your website is for Example, LLC, you might want to have www.example.com, www.examplecompany.com, and www.example.biz all point to the same site. You may even want to have www.awesome-widget.com for your awesome widget. Plus all those without the www in front. Knowing and setting one of those names to be the canonical name for your site and enabling canonical redirection can improve your search rankings.
We encourage (but do not require) you to use www.example.com as a canonical name rather than example.com in most cases. See this FAQ entry for an explanation.
Ordinarily, your site's document root (as seen by Apache) is /home/public. If you enable the per-alias document root feature from the site info panel in our member interface, the alias used will be added to the site's document root.
For example, if you have www.example.com configured as an alias for your site, then when someone visits it, Apache will treat /home/public/www.example.com/ as the document root. If you also have the alias other.example.com added to the site, then requests using that alias will be directed to /home/public/other.example.com/.
If no directory exists for a given alias, all requests for that alias will return 404. If a directory exists, but no alias has been added via our UI, it will not be recognized as an alias.
This feature can be very helpful if you have multiple sites that need to share some but not all of their data or if you have several sites with different content that are all based on a common framework. Using this feature can allow you to maintain one copy of the framework.
This feature is not a substitute for creating multiple sites. With this feature, one site is still just one site. There is no additional security, isolation, or protection implied by using this feature. Just as nothing protects https://www.example.com/one/ from the contents of https://www.example.com/two/, there is nothing between https://one.example.com/ and https://two.example.com/ if they are pointed to the same site by this feature.
Due to the internal security requirements for the Apache web server, .htpasswd files must be referred to by an absolute path. To find this path for your site, check the "Apache Site Root" value in the "Config Information" box on the Site Information page for your site.
For example, if you have a site named example and the .htpasswd file is in your site's /home/protected directory and your Apache Site Root value is /fsxx/example, your .htaccess file might read:
Although it should be impossible to retrieve an .htpasswd file using web access*, the Apache documentation recommends that you do not store .htpasswd files inside your document root. This is why we recommend using the protected directory instead. Whatever its location, an .htpasswd file must be world readable (or, at least, readable by group "web").
*Only the specific filename .htpasswd is protected from web access. If you use password files with other names in your public directory, they may be visible from the web, which is bad.
Due to the way our network handles incoming requests, it is not possible to use .htaccess files to block IP addresses from accessing your site; by the time the .htaccess file is considered, the incoming request has already been accepted.
However, we recognize the common desire to restrict accesses in this way. For this reason, we provide the ability to block accesses on a per-site per-IP basis at the edge of our network.
By default, all accesses are allowed. We maintain two lists for each site, an allow list and a deny list, which are processed in the order: allow, deny. Thus, an IP address that appears on both lists will be allowed. Entries to either list can contain either an IP address or a netblock specified in CIDR format (10.20.30.40/24).
You can see and manipulate your site's IP access controls (if any) in the "Config Information" box on the Site Information page.
To see exactly what blocked visitors see, visit blocked.nfshost.com, which blocks all visitors.
Once you have TLS working for your site, visitors to the HTTP version will be redirected to the HTTPS version by default, but you can control this behavior from our control panel.
Go to the Site Information panel for your site.
In the "Config Information" box, select the "Edit" button on the "HTTPS Redirection" line.
Set the Canonical HTTPS value to "on" if you want HTTP visitors redirected to HTTPS and "off" if you do not.
(Don't worry, this setting does not apply to any alias of the site that is not set up for TLS.)
You can also optionally indicate strict transport security. However, we don't recommend doing this unless you understand what it's for and how it works. If you get this wrong, you could potentially lock visitors out of your site for six months. The benefit is that if you do this, it will inform browsers to automatically use HTTPS to access your site, even if someone types in an http:// URL.
If you want to do this, add a line to an .htaccess file in your site's public directory something like:
Header always set Strict-Transport-Security "max-age=3600;" "expr=%{req_novary:X-Forwarded-Proto}=='https'"
Once you are very, very sure everything is working properly, you can change the 3600 to 15552000 and optionally add "includeSubDomains" after the semicolon to improve the rating of your site's security on sites like SSLlabs. However, be very careful in doing so, as this value represents 180 days, and if you make a mistake such as redirecting people to an HTTPS version of an alias that isn't set up for HTTPS, you can potentially lock them out of your site for that length of time.
Yes. Our servers support having more than one alternate name for
your site (such as www.example.com and another.example.org).
If you visit the Sites panel and then select
your site name in the "Short Name" list, you will see the Site Information page, where you can add and remove aliases at any time.
You may also add NearlyFreeSpeech.NET DNS to an alias at any time by visiting the Domains panel and choosing "Add" under the "DNS" column for the relevant alias (domain).
This can be very difficult. We wish we could push a magic button and take care of it for you, but the truth is that the scalability and performance of your site is much more under your control than ours. When sites encounter performance issues (such as 503 errors) under load, we almost always find that it is some problem with the site's programming that is responsible. Based on our extensive experience with such situations, we have prepared some general guidelines to help you design a site that is fast and scalable and remains available under heavy load.
First, if you are running WordPress, this information will not be much help. Basic WordPress installs are hopelessly incapable of surviving traffic surges. It requires extensive, specialized tuning to have a WordPress site that remains available under load. We recommend that you read and follow our Advanced WordPress Configuration guide, but even that is mostly in the nature of a good start.
For applications you are developing yourself, the following information may be helpful.
The basic principle of scalability is that however fast requests come in, they must complete at the same speed. If they do not, a backlog will form, response times will increase, and the site will eventually fail. This is the web's equivalent to the law of gravity: what goes in must come out. You cannot get around it.
Take advantage of our network to cache whatever you can. If you set Cache-Control: or Expires: headers for scripted content, our system can store copies in RAM and serve that content orders of magnitude faster than if you generate the same content over and over from a script for each request. (This is helpful primarily for content that is shared between users. I.e. if you personalize a page for each visitor -- such as by using cookies -- caching is unlikely to help. Keep this in mind when designing your site, and try to avoid using cookies or sessions where they are not needed, especially on top-level or high-traffic pages.)
Consider the availability, response times, and usage limits of any external resources your site depends on, like API's. The 100-requests-per-minute limit on that free message queueing web service (or mapping API, or geo IP lookup service, or whatever) you're using seems like a lot until you wind up on the front page of Reddit. Likewise, if your site depends on an external resource and that resource goes down, it's likely to cause timeouts on your site, and those can take forever, leading to a rapid collapse of the site.
Don't do anything that causes incoming requests to be serialized, as that will cause the site to work fine normally (or in testing), but completely collapse under even trivial load. Nobody intentionally serializes requests; it's generally the side effect of something that seemed like a good idea at the time. Making every request obtain an exclusive lock on the same file, like a log file, is one common way to do this. (N.B. if you use mod_rewrite and enable logging, it does exactly this.)
Your database can also be a source of performance problems. Although SQLite performs extremely well under low concurrency, it uses file locking and can have major scalability problems if any writes are performed. Don't use SQLite for an application you intend to scale unless it is read only, use MySQL instead. MySQL's base performance is slower, but it handles high concurrency much better. However, it is not a magic bullet. You should carefully consider indexing and locking, and monitor slow queries in order to get good performance from MySQL. With MySQL, there are often performance thresholds where exceeding a limit causes a dramatic drop in performance. One example is the use of temporary tables. Small temporary tables are stored in RAM. But large ones are written to disk, causing a dramatic drop in performance the minute a table exceeds the threshold for being stored in RAM.
If your site uses caching or temporary files (including PHP's default file-backed session handling), make sure the files are well-organized and routinely pruned. Directories containing tens of thousands of files that are traversed for every request can saturate your available I/O resulting in extremely poor performance.
If part or all of your application requires very high concurrency, particularly for long lived requests, don't use PHP. PHP's one-process-per-request model is not well suited to large numbers of concurrent requests, especially if they are mostly idle. Something like Node.JS is much more effective for that purpose and can scale to thousands of simultaneous connections, whereas PHP will typically choke at dozens. (Or, if it does not, you will likely choke when you see the bill; Node.JS not only handles high concurrency much better, but it also handles it much more cost effectively.)
Building scalable web sites is a high art, and the tips shared here only scratch the surface. But hopefully they offer a place to start on the long, hard journey to building a site that can handle hundreds of thousands of simultaneous users and dozens of requests per second. (And yes, we host those types of sites.)
If you configure a site type that supports arbitrary daemon processes, the infrastructure that initializes them does not process command line arguments. In the rare case that you don't need any, you can run the daemon executable directly from the 'Command' field of the Daemon management interface. In all other cases, you will need a run script.
A run script is a short shell script that lets you customize the environment for your daemon without worrying about the massive stack of stuff we have to do to make sure your daemon runs in the context of your site. A typical, minimal run script is an executable file that looks like this:
(The above is a fictional example; it is not a valid command. You will have to customize it for however your specific process specifies what port to use and to stay in the foreground.)
Then, you enter the path to the run script as the command in your daemon configuration. This lets you customize the daemon's command line arguments. You can also take other actions if needed, like setting environment variables, removing temporary files from previous runs, running preflight database checks, etc.
When writing run scripts, always make sure the following key elements are present:
The shebang line is the first line of the run script. (#!/bin/sh)
The exec command in front of the daemon executable. (Saves RAM = lower costs, may also avoid problems with signal delivery.)
The daemon process must run in the foreground. (Otherwise it will be repeatedly killed and restarted.)
Starting the daemon is the last line in the run script. (Anything after that will almost never be run.)
Executable permissions on the run script. (chmod a+x myrun.sh)
To set up a custom server process, follow these steps:
Make sure your site's Server Type allows daemon processes.
Create a Run Script that starts your custom process.
On the Site Information panel for your site, in the Daemons box, choose the "Add a Daemon" button.On the Add Daemon panel, enter information about your daemon process:
Tag: A unique (within your site's daemon processes) alphanumeric tag to identify this daemon.
Command Line: The correct path to your run script.
Working Directory: The current directory when the daemon is started. When using a run script, ignore this and include a cd command in your script instead. The correct working directory is dependent on the software you are running.
Run Daemon As: Web servers should always be run as the "web" user and support servers should typically be run as the "me" user.
The "Add Daemon" button will add the new daemon. The system will attempt to start it automatically within about a minute.
Watch the Site Information panel to see if the daemon process starts and use its log file to debug any issues.
If (and only if) your custom process is a web server intended to handle incoming requests, you will also need to create a proxy:
On the Site Information panel, in the Proxies box, use the "Add a Proxy" button.
Enter the correct information required by your daemon process:
Protocol: What protocol the system should use to communicate with your daemon process.
Base Path: Which part of the site should be directed to the daemon process. Must begin and end with a forward slash.
Document Root: What to replace the Base Path with when directing requests to your daemon process. Must begin and end with a forward slash. Some daemons need this to be based on the process's working directory (e.g., "/"). Others, including PHP-FPM, require an absolute path to the directory or routing script (e.g., "/home/protected/my-daemon/routing-script.php/").
Target Port: The TCP port number (in the range 1024 to 65535) where your daemon process listens for requests. The correct port number depends entirely on your daemon process.
Test and debug the proxy.
For additional information about this process and a complete example, please see the Django how-to on our blog.
Make sure that you have added aliases for both names to your site.
If you are using third-party DNS you will have to make sure that is properly set up as well.
If you have NearlyFreeSpeech.NET DNS for your domain, your authoritative name servers are the "official" name servers for that domain.
However, in order for these name servers to be used, you must take the list of authoritative name servers and make them active by entering them at your domain registrar (even if your domain is registered through us).
If you go to the DNS information panel and see both "Authoritative Name Servers" and "Active Name Servers" then you have NearlyFreeSpeech.NET DNS, but your domain registration points elsewhere.
If that's the case, you have two options to correct the problem:
If you want to use NearlyFreeSpeech.NET DNS, update your domain registrar's list of name servers to match the "Authoritative Name Servers." (Due to extremely long cache times associated with root name server records, it might take a long time for our system to reflect changes you make and stop displaying the warning message.)
If you don't want to use NearlyFreeSpeech.NET DNS, just remove it.
This scenario most commonly arises when you transfer an existing domain name from another registrar without updating the name servers first.
In that case, you just need to change them in our system once the transfer completes.
For maximum reliability it is always best to make sure that the active and authoritative name servers match. There are isolated reports of weird things happening if they don't, and some ccTLD registries (notably .DE) actually verify that they match before allowing changes.
First, when configuring third-party DNS, make sure that you have configured the names that you will be using for your site as aliases on the Site Information page. Otherwise, when the request gets to our network, our servers will have no idea what site you want and will return an "Unknown Site" error message.
The preferred way to set up third-party DNS is to create a CNAME record. This allows you to take full advantage of our load balancing and fault tolerance features to get the best performance and reliability for your site. If your site was named example and you wanted to use the domain name www.example.com then you would configure a CNAME record from www.example.com to example.nfshost.com.
However, you cannot use a CNAME record with a bare domain name (such as example.com without www. in front). All domain names have special records, called SOA records, which must exist. But CNAMEs must not coexist with any other records. So, if you attempt to point example.com to example.nfshost.com via a CNAME record, you will violate the DNS specification because the mandatory SOA record won't be there. This will cause all kinds of unpredictable and hard-to-diagnose problems with your domain.
In such cases (or if you just hate CNAME records) you can also use A and AAAA records with the IP address(es) for your site to set up third party DNS. They're at the bottom of the Site Information panel in the "Web Site Addresses" box.
The caveat with using A/AAAA records with third-party DNS is that you are then responsible to keep them up to date if they change. Fortunately, that's exceedingly rare, and in most cases the old IP will continue to work for several months. As long as you make a practice of checking on it from time to time (set a reminder!), it will typically be fine.
The major exception to "typically" relates to DDOS attacks. If there is a DDOS attack on a specific IP address, we may have to disable that IP address without warning and move affected sites to another one. If you're using our DNS, that's no problem. If you're using third-party DNS with CNAMEs, that's no problem. But if you're using third-party DNS and you're using manually-configured A records and the IP address you're using gets attacked and we have to block that IP to mitigate the attack, then you may experience downtime until you manually update your third-party DNS. Such circumstances are rare, but they do happen.
If you have NearlyFreeSpeech.NET DNS service, you may obtain your name server information from the DNS information page for your domain in our user interface. Just go to the Domains panel and, for the domain in question, under the "DNS" column, click "Manage." The name servers for your domain are listed in the "Authoritative Name Servers" box.
If you are using third party DNS, you must get the name server information from your DNS provider.
If you do not have NearlyFreeSpeech.NET DNS and you do not have DNS from a third party, you do not have name servers and will usually not be able to use domain names with your website, except through "masking" or "forwarding" offered by some domain registrars.
If you're registering a new ccTLD domain name with a third-party registrar and you're planning to use NearlyFreeSpeech.NET DNS, and you run into a situation where the registrar needs you to have valid name servers before you register the domain, send us an Assistance Request and we'll add the domain and activate DNS for you.
In order to add NearlyFreeSpeech.NET DNS to an existing website, follow these steps:
Go to the Site Information page for your existing site by visiting the Sites panel at the top of the page, and then selecting the site's "Short Name" from the "Sites" list.
Choose "Add a New Alias" in the "Site Names & Aliases" box to add the new site name.
Add the new site name, including the www (such as www.example.com). This tells our system which site the new name points to.
Once you have finished adding the name, you will be returned to the Site Information page. If you added the name correctly, you should see it listed in the "Site Names & Aliases" box.
For the alias you just added (here listed under the "Domain" column), under the "DNS" column, click "Add."
Decide how you want email handled for this domain by choosing the appropriate selection.
That's all there is to it!
If you've already registered your domain with a third-party registrar when you set up NearlyFreeSpeech.NET DNS, don't forget to update your list of name servers at your domain registrar with the name server information we provide for your domain.
No. When you create NearlyFreeSpeech.NET DNS for a site named www.example.com, your NearlyFreeSpeech.NET DNS is actually being set up for your registered domain, example.com. You may add as many subdomain names as you want to an existing NearlyFreeSpeech.NET DNS domain at no additional cost.
Multiple names can each point to a different site, all point to the same site, or any combination you need.
(In order for this to work, you must first have set up NearlyFreeSpeech.NET DNS for your domain name. If that is not already done, start with this FAQ entry and then return here.)
Select "Manage" in the "DNS" column for your domain name.
On the DNS Information page, find the "Authoritative Name Servers" box and copy down the information. (You'll find two server names of the format ns.xxx0.nearlyfreespeech.net.)
Go to your domain registrar's site and find the option to change name servers.
Replace whatever name server information they currently have with the information you found in the "Authoritative Name Servers" box.
Since each registrar has a slightly different way of editing name servers, you would need to contact them for specific help with using their system.
Once these steps are complete, you may have to wait awhile for the change to take effect. Changes in most top-level domains take less than 24 hours, and the major ones (.com, .net, and .org) often take effect within a few minutes.
If your domain registrar provides DNS service, you can also use that, although it is not recommended. Please see this FAQ entry for more information.
Choose "Create a New Site" from the "Actions" box.
Add a "short name" for your site to use on our system. (You might be asked which account to assign the site to, if you have more than one eligible account).
On the "Use another name?" screen, select the "Yes" button and use the text-entry field to the right of "If so, what is it?" to add your subdomain as an alias to your site.
You may also add additional subdomains to a site you already have, by following the instructions in this related FAQ entry.
We do not use or support the scheme of placing subdomains in subdirectories of your existing site that is employed by some mass-market hosting control panel options.
SPF is the Sender Policy Framework, a way to use DNS to tell the world about the servers that can legitimately send email for your domain. It is an anti-spam tool that makes it a little easier to identify spam, and a little harder for spammers to hide.
We've noticed that many of our members register more domains than they need for email purposes. For example, someone whose domain is example.com may also register example.net or other similar domain names to prevent competitors from creating similarly-named sites. But they only use their primary domain for email.
Our "SPF Email Protection" feature is an easy, automatic SPF record that will tell the world that your domain isn't used for email. That will help foil spammers who might otherwise forge email from that domain, as described in this FAQ entry. That means that spammers have one less place to hide, and also that you won't get their bounce messages.
Our standard offering is designed to be easy to use for this common case. If you need more specific settings for SPF, you can create your own custom TXT record for your domain containing any SPF code you want. The specific code you need depends on the server you use to send (not receive) email, which is usually your ISP's mail server.
To find out what SPF code you should use, or to learn more about SPF and how it can help you, check out the SPF home page.
SPF isn't suitable for all cases. For example, it doesn't work well if your domain sends email from a number of different or frequently changing places. But where it is suitable, it both helps you a little bit, and it's a way to be a "good netizen" to your Internet neighbors by making spamming just a little bit harder.
Anyone who wants to send mail from their domain from our servers and wants an SPF record for it should refer to this FAQ entry instead.
For the relevant domain, under the "DNS" column, select "Manage."
Use the "Add a DNS Resource Record" action to add each MX record given to you by your email provider:
Leave the "Name" field blank to apply forwarding to your whole domain.
Select the "MX" type.
Enter both the MX preference and the destination host in the "Data" field, separated by a space. Be sure to enter a "trailing dot" (a period) at the end of the destination hostname. (Example: "0 mail.example.com.")
The IPv4 (and IPv6, if enabled) addresses listed at the bottom of the Site Information page, under "Web Site IP Addresses," are used by our web servers. They are not alternate addresses for our name servers. They are provided for reference only and almost never need to be used e.g. from DNS records.
For more information about how those IP addresses work with our service, see this entry.
If you are trying to obtain DNS name server information, please read this entry.
These instructions assume you have turned on our DNS and that your domain name registration has our name servers listed. To turn DNS on for a new domain, see this FAQ entry; to turn it on for a domain you've newly registered with or transferred to us (that wasn't already using our DNS), see
this one.
Select "Manage" under the "DNS" column for the relevant domain. (If this column says "Add" it means we are not providing DNS service for that domain. If you add it, you will have to update your domain registration.)
On the DNS Information panel for your domain, in the upper right corner, inside the "Actions" box , select the "Add a DNS Resource Record" action.
Detailed instructions for setting up different record types are included on the "Add a DNS Resource Record" panel.
Click "Manage" under the "DNS" column for the relevant domain.
In the "Additional Resource Records" box, find the resource record you want to remove and select the "Remove" button to the right of it.
If the record you want to remove is in the "NearlyFreeSpeech.NET Resource Records" box then it is a component of some service we are providing to you, so it cannot be removed without removing that service. For example, if a DNS record matches an alias of a site you have hosted here, then you won't be able to remove the record. If you remove that alias from your site, then the DNS record will automatically be removed as well. See this related FAQ entry for more information.
Using URLs with bare domains (like https://example.com/) creates several problems, and we strongly recommend that you avoid it for anything other than redirecting to the real website (like www.example.com).
Some of the limitations are:
It creates noncanonical URLs for your site.
It is
highly desirable to have one URL for each page for purposes of
bookmarking, etc. Having multiple valid URLs for the same page (e.g., https://example.org/about-us and https://www.example.org/about-us) makes your site look less popular, for example, in search engine rankings.
It is less reliable.
DNS CNAME records cannot be used with bare domain names.
With our service, this is only an issue with third-party DNS, but if you're doing that with example.com, it's not as effective for load balancing and fault tolerance as doing it the "right" way.
It becomes hopelessly confusing if you have (or might ever
have) more than one website under the domain.
Which site does example.com refer to? The "most important" one? Get ready for a knife fight between the site developers over whose site is the most important!
One name should do one thing.
Bare domain names already organize the domain, and often they do email
duty as well. Web traffic is better kept in a separate box. This aids in filtering, debugging, and compartmentalizing services. (We also see many domains with A records that result in the Internet trying to deliver the domain's email to our web servers. Hint: Not gonna work.)
Despite the drawbacks, this is something that visitors to your site expect to work, and we know that.
The best compromise is to redirect visitors from example.com to your www.example.com alias. To do that, add both www.example.com and example.com as aliases to your site and (unless you are using WordPress) enable canonical name redirection. If you are using WordPress, it will manage your hostnames automatically, and you should leave canonical name redirection off (the default).
There are, of course, exceptions; this is more of a guideline than an actual rule. It may make sense to forego the www for a business website if the website is the business. Sites with very short names are also perpetually trendy, and knocking "www." off the front in service of shortness is one way to chase that trend.
If you're sure you're an exception, apply these recommendations in reverse to direct visitors from www.example.com to example.com.
No, although we plan to add support for wildcard aliases in the future, the feature is currently in limited beta. If you are a subscription member and need this feature urgently, please get in touch with us through the support tab, and we can see if we can meet your needs.
If you run into this, it is most likely a CNAME or A record that was automatically created by our system when you added a corresponding alias to one of your sites because you wanted our system to know that a certain hostname (such as www.example.com) should be used with that site.
If this is your situation, the record in question will appear in the "NearlyFreeSpeech.NET Resource Records " box on the DNS information panel for your domain and will typically look similar to:
www.example.com CNAME example.nfshost.com.
or
example.com A 10.11.12.13
If you want to remove a DNS record associated with a site alias, like a CNAME record pointing to an .nfshost.com name, visit the Sites panel and select the relevant site's short name. The Site Information panel will list the aliases and provide "Remove" buttons in the "Site Names & Aliases" box. Removing the alias will automatically delete any related records from your DNS.
First, it can be done through our API, which does allow the dynamic modification of DNS records. This approach can be a bit convoluted, but many smart people have written and released scripts and libraries to help streamline the process. Searching the web for "NearlyFreeSpeech.NET dynamic dns" should produce a variety of options.
The second approach is to set up a name for your home machine with a dynamic DNS provider like No-IP.com (which offers a free service), or Dyn. In the case of No-IP.com, they will give you a name like your-name.noip.com and you can load a widget on your home computer or Internet router to keep the address up to date. Then, from our end, add a DNS record for the name you want that is a CNAME to the name they gave you; i.e. if you want www.example.com to point to your home machine, and they gave you example.no-ip.com, you would add a CNAME DNS record here in your example.com domain with a name of "www" and a data value of "example.no-ip.com." including the trailing dot.
Yes, manual setup of your DNS on a geographically and administratively independent secondary name server is available on a per-domain basis as an Assistance Request.
This service is set up manually on purpose. It would be relatively straightforward (if somewhat failure prone) to set it up automatically, but doing so would create a dependency relationship between the offsite name server and the primary one. That doesn't completely eliminate the reliability benefits of having a geographically diverse name server, but it does greatly diminish them, so we don't do it that way. Our goal is for our secondary DNS to be as close as we can make it to having secondary DNS from a completely separate provider.
If your DNS appears to stop working after you move it here from another company that was managing both your domain registration and DNS, check to make sure DNS is enabled and then try querying our servers directly. E.g.: see if running a command like:
YourPrompt$ dig example.com soa @ns.phx1.nearlyfreespeech.net
returns something like:
;; ANSWER SECTION:
example.com. 3600 IN SOA ns.phx1.nearlyfreespeech.net. hostmaster.nearlyfreespeech.net. 1234567890 600 180 86400 180
(Use your correct domain name and one of your assigned name servers shown on the DNS Information panel in place of example.com and ns.phx1.nearlyfreespeech.net.)
If all those steps work but your DNS still isn't visible from the outside world, e.g.:
it could indicate that your DNS change hasn't propagated yet. In that case, all you have to do is wait.
However, there is another step you should take. Check to see if your domain has DS records:
YourPrompt$ dig example.com ds @8.8.8.8
and look for a line like:
example.com. 3600 IN DS 12345 1 2 (lots of text) 12345678
If you find one, it's probably what's breaking your DNS.
If your registrar/DNS provider set up DNSSEC, which they may have done without telling you, they installed DS records into your domain registration. If you didn't explicitly remove those records before changing your name servers, they will continue to exist. As long as they do, no one else's DNS (i.e., ours) will be accepted as valid.
DS records are part of your domain's registration, not its DNS. Make sure you look in the right place for them. For example, on our system, DS records are shown on the Registration Details panel, not the DNS Information panel.
We don't currently use DS records, so if your domain has any, you need to remove them.
If you transferred your domain registration to us, any DS records it had came with it. To remove bogus DS records for domains registered here, see this related FAQ entry.
On the Registration Details panel, in the Registration Details box, on the Name Servers row, use the Edit button.
Decide whether you want to use our DNS service.
If so, choose "Set up DNS and name servers automatically."*
If you want to use third-party DNS, choose "I want to specify my own name servers."
Use the Continue button.
If you chose the automatic setup option, no additional steps are required.
If you chose to enter your own name servers, do so on the Enter Your Name Servers panel, then use the Continue button.
*If you already have DNS for this domain in our system, selecting this option will preserve any existing custom DNS records.
Please keep in mind when changing name servers that most registries publish DNS records with 48-hour time-to-live (TTL), so it may take up to two days for name server changes to fully propagate.
Each inbound domain transfer from another registrar has the following steps:
Verify that you have an account with sufficient funds available to make the transfer.
Make sure the domain is eligible for transfer. (I.e. that it has not changed ownership or been registered, renewed, or transferred in the past 60 days.)
Unlock the domain at the current registrar.
Obtain the transfer code (also known as "auth info code" or "EPP code" or "transfer secret") from the current registrar.
Make sure that the current registrar has a valid email address for the domain's administrative contact and that you know what that address is.
The info panel for your domain will show that it has an Action Status of "Transfer waiting for Admin Contact Approval."
Check the email for the domain's administrative contact for a message with a link to a web page where you can approve the transfer.
Approve the transfer on that page.
The "Registration Details" page for your domain will show that it has an Action Status of "Transfer waiting for Losing Registrar Approval."
Wait up to seven days for the current registrar to release the domain.
When the transfer is finished, the Action Status and Transfer Status entries will disappear and be replaced by one Status entry that says "Active."
If the transfer fails, it may linger in our system for a bit, but it will ultimately be refunded and the "Registration Details" page for that domain will be completely removed so you can try the transfer again.
These are the high-level steps. This section of the FAQ contains many other entries that provide detailed information for the various steps.
If you let your domain expire, you can usually renew it as normal during the renewal grace period. After that, it moves into the deletion process.
Here are the states a domain goes through during the deletion process:
Queued for deletion ("QueuedForDeletion")
Domains "queued for deletion" are in a weird limbo state between renewable and restorable. They are no longer eligible for regular renewal but cannot be restored yet. Their status should shift to "pending delete restorable" after about seven days.
This is typically the only state where a domain can be restored after the renewal grace period ends. The duration of this state varies by TLD but is usually in the range of 30-40 days.
Pending delete ("PendingDelete")
This is the last state before deletion. Once a domain moves into this state, it can no longer be restored and must be re-registered as a new domain once the deletion is completed. This state typically persists for one to three days.
If your domain is in the "PendingDeleteRestorable" state, you can place a restore order. However, registries charge a hefty fee for such recoveries, which we must pass along.
The fee to restore a domain is shown on our public site. It varies widely between top-level domains. We do not profit from this fee and have no control over the restoration process. We are merely passing along our costs.
What does this mean? If your domain has expired and is now past the grace period, you have two options:
Pay the stiff restoration fee to recover your domain.
Wait for the domain to be completely deleted and then try to re-register it.
If you want to restore a domain, use the "Restore" button on the "Status" line of the "Registration Details" box of the "Registration Details" panel for your domain in our member interface. If there is no "Restore" button there, the domain is not in a restorable status.
If you choose to wait, you risk the domain being registered immediately upon deletion by domain profiteers. The chance of this happening is based on the domain's previous popularity and public perception of its traffic stats. If a profiteer registers the domain, they will often want hundreds or thousands of dollars to sell it back to you.
If you choose to pay the redemption fee, it may take one or two days for the domain to reactivate fully. As with all renewals performed after the expiration date, there is no way to speed this up.
Neither choice is attractive, so we recommend against letting your domain registration lapse unintentionally. If a domain you want to keep expires, renew it immediately. But try to avoid letting important domains expire at all. There is no penalty for early renewal, and we offer domain auto-renewal for critical domains that must not be allowed to expire.
If you are in this situation and want to pay the redemption fee:
In the domain list, select the "Manage" button in the "Registrar" column for your domain.
On the Registration Details panel:
Find the Registration Details box in the upper left.
Find the "Status" line.
Select the "Restore" button.
Read the Restore Domain panel.
If you want to restore the domain, select the "Place Restore Order" button.
It is typically unnecessary, but you can also request a manually-assisted restore through our assistance request system; the manual restore cost is $5.00 higher than the automated restore cost to cover our manual processing time. (This extra cost for a manual restore is waived for subscription members.) However, we do not have any special powers to restore domains beyond what the interface provides. This capability is useful in an emergency if the registrar's automated systems are having problems.
When you place an order for a domain transfer, the registrar sends out an email to the current administrative contact's email address requesting approval of the transfer. Some proxy registration services automatically discard this message, making it impossible for you to transfer your domain away. Your only option is to cancel the privacy service before initiating the transfer, thus exposing your personal information. Unless you are willing to temporarily forego your privacy you can never switch away from that registrar, which is why we call this situation "extortion by proxy."
To avoid delaying your transfer, we strongly recommend that you cancel any proxy registration service before you initiate the transfer. Since not all changes happen immediately, you may wish to consult the whois information for your domain to make sure it has been cancelled before placing your transfer order.
If you have already placed your transfer order and you find yourself in this situation, you will have to cancel the transfer or wait for it to fail (usually 7-30 days from the time you place the transfer order). See this related FAQ entry for complete details.
Our members have reported encountering this problem with several proxy registration services. (Naturally, RespectMyPrivacy does not have this limitation, as it is designed to respect your privacy, not prevent you from controlling or transferring your domain.)
In most cases there will be no disruptions. The only thing that might be interrupted would be if you are using DNS service with the current domain registrar. It's possible they will terminate that service upon transfer of the domain, so you might want to switch the DNS service either to us or a third party before you transfer the domain to us.
Assuming that your DNS is valid and continues to operate, there should be no interruptions in any services tied to that domain during the transfer.
Your name server information is not updated during a domain transfer. To avoid problems, we strongly recommend that you update your name server information at your old registrar before you initiate a domain transfer.
If you are obtaining DNS from your old registrar and you don't update your name servers, they will probably remove your DNS service when they process your transfer. This typically manifests as your domain suddenly going to the old registrar's parking page or failing outright after the transfer completes.
To find out how to update your name servers on another registrar's system before a transfer, contact them directly.
If you have already transferred a domain without changing the name servers and you now need to update them, please see this related FAQ entry.
Yes, you may use our member interface to add or remove RespectMyPrivacy service on any domain registered through NearlyFreeSpeech.NET at any time, as long as the registration is not expired and the TLD supports private registrations. The .us TLD is currently the only one we offer that does not support private registrations.
To add it: Visit the Domains panel. Under the "Registrar" column, select "Manage" for the relevant domain. The Registration Info panel for your domain will have an "Add RespectMyPrivacy" action in the "Actions" box.
To remove it: Visit the Domains panel and, under the "Registrar" column, select "Manage" for the relevant domain. The Registration Info panel for your domain will have a "Remove RespectMyPrivacy" action in the "Actions" box.
No, we are not. We have integrated the registration services of Public Domain Registry, an ICANN-accredited domain registrar, into our member interface to provide domain registration. Public Domain Registry enables us to offer great prices and, more importantly, enables us to support our members ourselves, all the way through the domain registration process.
We have on several occasions considered ICANN accreditation and decided against it. The development effort required to individually integrate different systems for each registry would significantly detract from our core mission to develop the best possible web hosting. It would also incur a lot of development expense and accreditation costs to recoup, which for a company of our relatively small size would most likely translate to several years of higher prices for domain registration. And yet, our domain registration service would be essentially identical to what we can already offer. Since the actual service for any given TLD is ultimately provided by the registry for that TLD, domains don't offer a lot of room for innovation at the registrar level. Charging significantly higher prices for the same service -- or, at best, maybe 1% better -- doesn't sound that great.
In addition to that, we sort of like our current position. With few exceptions, the domain registration industry is dominated by large players locked in a mortal race to the bottom of the barrel in terms of price and quality. They can and do make mistakes and cause problems for their customers. This is particularly visible in how they handle complaints. A billion-dollar company making a few pennies off of a domain didn't get to be that size because they keep a team of lawyers on standby to scrupulously hold every complaint about every domain to the highest legal standard.
If your registrar makes a mistake or a dumb decision... and they all occasionally do... you probably won't have their entire executive & technical staff on your contacts list. We do. And if we agree it's a dumb decision, we do not hesitate to use those contacts to "advocate vigorously" (and typically very, very effectively) for our customers on those rare occasions when things go awry. In fact, our registrar has learned to contact us with complaints about domains registered through us before they do anything, rather than after the fact, so we've even been able to head stupidity off at the pass more than once. Don't underestimate the power of having an 800-pound freedom-loving gorilla in your corner! (But don't overestimate it either. Public Domain Registry isn't perfect; no registrar is. Although it's extremely rare — like "count the cases on one hand with fingers to spare" rare — they do have the right to handle a situation in a way we disagree with. And, of course, if a domain gets suspended or canceled for good reason, the gorilla is totally fine with it.)
We offer three renewal settings, which can be selected or changed at any time via the Renewal Monitor or the info panel for the domain:
Automatic Renewal - Your domain will be automatically renewed for an additional year about a week before expiration, as long as you have sufficient funds to do so.
Manual Renewal - We will send you reminder emails, starting about a week before your domain expires. This is the default setting for all domains.
Do Not Renew - Your domain will be allowed to expire.
If you select automatic renewal, your domain will automatically renew and you will be charged for the renewal, as long as your account balance is high enough. If your account has insufficient funds to process the renewal our system will keep trying once per day until you disable auto renew, the domain expires and is deleted from our system, or you deposit enough funds for the renewal to succeed. Each time our system attempts to auto-renew a domain, you will receive an email with the results (success or failure). This means you will get daily emails when a domain is about to expire (and for some time afterward) if you do not have enough funds available. Remember that domain renewals are non-refundable, so be sure that you only enable this setting if you are sure you want the domain to auto-renew.
If you select manual renewal, you will receive email reminders, beginning a week prior to your domain's expiration, but since domain registration is so important, we encourage you to have your own reminder, in case ours get lost or misfiled as spam.
If you select not to renew, you may still renew the domain at any time, but it will not automatically renew, nor will you receive any reminder emails. This option is most appropriate for domains that you intend to let expire.
Note that in addition to whatever settings you have with us, ICANN mandates three additional reminder emails be sent; one 30 days before your domain expires, one 7 days before, and one when it expires. There is no way to control or suppress these messages, because ICANN feels they know better than you (or we) what sort of reminders you should be sent about your domains.
Yes. Note that if you recently registered or transferred a domain, you'll have to wait until the sixty-day waiting period is up before you can transfer it again, to us or another registrar.
If 60 days have already elapsed since you registered or renewed it, you can transfer it, and you'll not only keep your existing time you already paid for with the current registrar, but we'll also give you an additional year, starting from the current expiration date, as part of the transfer. (However you cannot cause a domain registration period to exceed 10 years, so if your domain is already registered for 9.5 years, and you transfer it, it would be set to the 10 year period and the remaining six months would be lost.)
Do note that if you prepaid for another registrar's privacy service, they are unlikely to refund that to you, so that money would probably be lost.
The reason for this depends on the domain transfer status.
First and foremost, if your domain transfer status is "Transfer waiting for Admin Contact Approval" then you need to take action. Check the domain's current administrative contact email address for a confirmation message with a link to a site where you must choose to approve or decline the transfer. If you haven't received this message, you can resend it from our UI, but please make sure you're checking the right email address. If we don't get confirmation within five days, the transfer will fail.
Once you confirm the transfer, any domain registrar is entitled to stall an outbound transfer for up to seven days. If your domain is in this state, it will show up in our system as "Transfer waiting for Losing Registrar Approval."
Some registrars simply make you wait the full period. Other registrars offer a way to expedite the transfer from their site, even if they send you an email saying you don't need to do anything. However, of these, a few registrars don't actually implement anything as a result of approving the transfer and still make you wait. Some registrars don't impose any additional delay at all; we have seen people place transfer orders that were fully completed within hours, while many others have to wait the full seven days every time.
Because this delay is imposed by the registrar you are transferring away from, we have no control over it and cannot help to expedite your transfer.
A much less common domain transfer status is "Could not Fetch Current Administrative Contact Email Address. Will attempt again every hour." This means there is a problem retrieving the admin contact email address from the domain's current registrar. This is an internal problem related to the registry protocol (EPP) and can occur even if the whois information appears correct. This status is typically auto-correcting within 12-24 hours and no action needs to be taken on your part and nothing you or we do can speed it up. In some very rare cases, it will take too long and the transfer will fail. If that happens, simply wait to be refunded and try again; generally the transfer will go right through on the second attempt. If this happens twice, try changing the administrative contact address if possible.
Should a transfer fail for any reason, we will notify you promptly via email.
The first (and possibly most important) thing that happens when your domain expires is that it stops working. Its name servers are withdrawn from the registry's master DNS servers and replaced with "parking" records by the registrar.
These parking records will cause ads to be shown on your domain. (This unfortunate policy is ubiquitous in the wholesale registrar industry that we have to use to register domains. It is not something we have control over, and not something we profit from.) Due to the 48-hour TTL (time-to-live) records used for name server glue records by the domain registries, these ads may continue to display for up to 48 hours after an expired domain is renewed.
In addition, at the time of expiration, the domain's publicly-visible contact information becomes frozen and cannot be changed under most circumstances. This has implications for domains with RespectMyPrivacy.
After expiration, your domain enters the "renewal grace period." This is (usually) a 30-day period* during which the domain can be renewed at the regular cost. If you renew during this period, your domain will be reactivated immediately, but it can take up to 2 days for the renewal to be visible all over the Internet.
After the renewal grace period, the domain enters the "redemption grace period," during which its status will be listed as "queued for deletion" or "pending delete restorable." During this period, usually 30-35 days**, the domain can still be renewed, but it costs a lot more.
(Any renewal during either grace period will be effective as of the original expiration date; you can't get extra time by renewing after the domain expires, nor do you lose time by renewing early.)
After the redemption grace period, the domain enters the "pending delete" status, where it typically remains for five days. It cannot be renewed during this period. After that, the domain is really, really gone and is free to be re-registered. Thus, the average domain can linger for as long as 75 days after deletion.
For awhile, it was the case that virtually every deleted name was instantly snapped up by speculators, but as of August 2008, that seems to be somewhat less common than it was. Nonetheless, the more valuable your domain is, the more crucial it is that you not take the chance.
*The length of the grace periods is not set by us and changes from time to time without notice to us. Thus we can't guarantee the lengths referenced here. Renew your domain as soon as you can if you care about it.
**Redemption grace period lengths also vary by TLD. For example, the .NAME domain currently provides only a five-day redemption grace period.
If you transfer the domain without first updating the name servers, this can happen even if you have set up your DNS here. Your domain will continue to point to the old DNS servers until you update it.
To update the domain:
Go to the Domains panel and, under the "Registrar" column, choose the "Manage" button for that domain. This will take you to the "Registration Details" page.
If your domain is locked, the "Actions" box will only show "Unlock this domain." Unlock it if it's locked.
Return to the "Registration Details" page and, in the "Actions" box, click "Edit Name Servers."
Select "Set up DNS and name servers automatically" on the following page.
Lock your domain, if desired, to help prevent hijacking.
The purpose of RespectMyPrivacy is to keep your contact information out of the public WHOIS database while still permitting you to be contacted if necessary. Expired domains persist in that database, complete with publicly visible contact information, for a really long time before they are finally deleted.
ICANN does not allow changing the contacts on an expired domain, so it is not possible to remove privacy service after expiration and before deletion. Once your domain is deleted, RespectMyPrivacy will be automatically canceled.
To remove RespectMyPrivacy from a domain that is not expired, see this FAQ entry.
Our domain registration services are designed and intended to be used in conjunction with our hosting services. Child name server records (AKA glue records) are used only when you are maintaining your own dedicated DNS servers, and therefore are not needed or used by the vast majority of our hosting customers. Consequently, we do not provide this feature via our member interface. (Although if you have any, they will be shown on the "Registration Details" page for your domain.)
However, if you have a need for child name server records in your domain, send us an assistance request containing the hostname and IP address(es) for the desired record(s). You will be charged a nominal fee (usually $0.50 - $1.00 depending on the number of changes) to cover the admin time required to manually perform these changes on your behalf, although this charge is waived if you have an active subscription membership. Please make sure your domain is unlocked when requesting child name server maintenance, and that you let us know you are aware of the extra charge so we don't have to redirect you to this FAQ entry.
The maximum is ten (10) years in all cases. In the case of transferring a domain to us and getting the additional year we include, if you already have more than 9 years left on the existing registration, you would receive from us approximately whatever additional amount of time would bring the total to ten full years, i.e. since you can't go over 10 years, we would give you less than a full additional year.
If you receive this error while attempting to make changes to your domain's name servers, it means the registrar rejected the names you provided. There are several reasons why this can happen:
The "new" name servers aren't different than the old ones.
The domain is locked, expired, or suspended.
One or more of the requested name servers hasn't been registered.
(Where possible, our system will give you the best information it can about the reason for the problem.)
These are pretty self-explanatory, except for the requirement that name servers be registered. If you want to use a name server like ns1.example.com, that name needs to be registered as a child name server (along with its IP address) by the registrant of example.com in order to create the necessary NS pointer records ("glue records") at the gTLD registries. If you got these name server names from someone else, check with them to ensure the names have been registered as name servers. If you registered the domain containing the name server names here and now need to create new child name servers, see this FAQ entry for instructions.
Unfortunately, the error response they return is often neither human nor machine readable, so it does not indicate which of these is the case in a way we can automatically display. (Note: this issue is substantially less prevalent than it used to be.) If you are a subscription member and you do hit an error our system cannot decode, we can manually look it up for you in our logs and convert it to a human-readable explanation; just open a support issue.
Whois verification is part of a new program started by ICANN in 2014 called the Whois Accuracy Program Specification. It is poorly implemented, dangerous, does not meet its stated objectives, and like all good pointless self-imposed bureaucratic processes, it's mandatory.
Anytime you change contact information associated with a registered domain, including when you first register it, you must verify the new contact email address. This is done by sending you an email message with a link to click on. The email will be sent to the registrant contact's email address. If you have RespectMyPrivacy for the domain, the message will be automatically relayed to your NearlyFreeSpeech.NET member contact email address.
We do not get to control when this message is sent, its content, or whether or not your spam filter will take it seriously. If you do not click on the link, two reminder emails will be sent over the next two weeks. If you still don't click the link after 15 days, ICANN requires that the domain be suspended until you do. If a domain is suspended, it can take 24-48 hours to start working again.
Even worse, if you don't complete whois verification for one domain and you have other domains that use the same contact information, all those domains will be suspended as well.
If this has happened, or if the verification is currently in progress and you don't have the email, you can request a re-send at any time from the registration info panel in our UI.
Please note: This policy has nothing to do with us. It applies to any domain in any ICANN-controlled gTLD, regardless of what registrar you use. If you have an opinion on this program that you would like to share with ICANN, you should feel free to direct it to the nearest brick wall. ICANN is not currently accepting public comment or feedback on this issue. That's just how they roll.
To transfer your domain to another registrar, you will need a transfer code, also known as an EPP code, auth info code, or transfer secret.
To get the transfer code for a domain registered here:
Go to the domain's "Registration Details" page, reachable by selecting the "Manage" button for that domain in the "Registrar" column on the Domains panel.
Make sure your domain is unlocked. If it isn't, stop and do that first.
Select the "Retrieve Transfer Code" action from the "Actions" box.
Enter your password on the Retrieve Transfer Code panel.
Select the confirmation checkbox.
Select the "Retrieve Transfer Code" button.
A transfer code will be generated and displayed on the resulting page.
If you intend to transfer a domain to another registrar, or if you do not see the "Retrieve Transfer Code" action after unlocking your domain, please see this related entry.
If there's a gTLD you're interested in that you don't see on our list, feel free to ask about it in our forum. We can tell you:
whether it's possible for us to add that gTLD (i.e. whether it is available through the registrar we use)
approximately what the current price would be
whether manual registration in that gTLD is available to subscription members
We cannot tell you whether or when we will add a given gTLD to those available on the site. But asking in the forum will let us know that someone is interested in that gTLD (which, if we're honest, is not the case for an awful lot of them). That's useful information for us when we try to figure out which gTLDs are worth the effort.
This applies only to gTLDs. It does not apply to ccTLDs.
We have no current plans to offer ccTLDs other than .us.
The actions for editing a registered domain are found on the domain's "Registration Details" page. On the Domains panel, click the "Manage" button in the "Registration" column for the relevant domain.
When a domain name is locked to prevent hijacking, it may not be transferred. Consequently, transfer-related actions will not appear if the name is locked. If you need to make these kinds of changes, unlock the domain first, and these options will appear in the "Actions" box.
The requirement for valid contact info in your domain whois information is an ICANN requirement, not a requirement of our TACOS. Although historically this requirement was only enforced in response to complaints, that is no longer the case. In response to pressure from the world's law enforcement agencies, ICANN has expended no effort at all defending your online privacy and quite a bit generating new procedures for validating domain contact information.
Anytime you transfer a domain or modify its contact information, a verification email will be sent to the registrant's contact email address containing a verification link. If you do not verify the email address (by clicking the link) a couple of reminders will be sent, but if verification isn't completed within 15 days, the domain is required to be suspended. This is really bad. Even after verification is completed, if the domain has been suspended, it can take up to 48 hours to restore full functionality.
If you have RespectMyPrivacy service for your domain, the verification email will come to your member contact address.
This is not a policy we have control over. We can't make exceptions, override it, or change how it's done. It applies to all domain registrars equally.
Related to this, there are a couple of other situations where domain contact information problems can crop up:
An ICANN-mandated message is sent to the registrant of each domain once a year, six months offset from the renewal date. If this message bounces, it is considered indicative of incorrect contact information.
ICANN has also streamlined the process for members of the public to report inaccurate whois information. As has always been the case, if you use invalid contact information on your domain, especially if you host any controversial content, you're handing people who disapprove an easy way to cause trouble for you.
Usually in these cases, since the registrar can't reach the domain contact, they alert us before suspending the name, but the steps vary based on the circumstance.
It has always been important to maintain valid contact information for your domains. With these changes, it is more important than ever.
As soon as our system records the failure of the domain transfer, you will receive a refund of the transfer cost and you can try the transfer again.
We are not automatically notified of transfer failures, so our system polls for them periodically. It may take an hour or two after the failure for our system to learn about it and process the refund. Between the time when the transfer fails and the time our system is notified of it and processes the refund, your transfer status will report as "deleted."
Please note that if your transfer fails you cannot re-attempt the transfer of that domain name until the refund is issued. Also, you should not re-attempt the transfer until you have understood or resolved the issue that prevented the previous transfer.
No, we cannot. The administrative contact must approve the transfer by responding to an email message, and the email address that must be used is the one that is active at the time the transfer is initiated. It would facilitate domain hijacking if there were a way to start a transfer and then override who approves it.
If you have started a domain transfer using incorrect contact information, you have the option of requesting that it be cancelled by using the "Cancel Transfer" link on the domain's registration information page, which is accessible from the Domains panel, using the "Manage" button under the "Registrar" column for that domain.
If you don't cancel it, the transfer will fail on its own and be refunded, which generally takes seven days from the initial transfer request.
In either event, you can retry the transfer as soon as it fails and you see the refund in your account balance. Make sure you have the correct administrative contact email address before retrying the transfer!
Be careful to update the administrative contact without altering the registrant information. If the registrant information is updated, your old domain registrar may refuse to transfer the domain for 60 days. (They're not really supposed to, but sometimes it happens anyway.)
Yes. If you have subscription membership and more than 10 domain registrations, renewals, or transfers to process in a single batch, you can create a list of domain commands and paste them into an individual support issue. We'll run them for you, charge you accordingly, and send you back the results. Please do not send us a list with less than ten actions, or a list that contains more than one action for a domain, as we will not be able to process them.
Here are some examples:
register example.com
register example.net private
register example.biz auto
transfer example.org abcd12345678 auto
renew example.net
If you want our RespectMyPrivacy.COM service, you can just add "private" to the end of a "register" or "transfer" line for the domain you want it set up for. Similarly, if you want registrations to auto-renew year after year, you can add "auto" the same way.
Bulk transfers preserve your existing name server settings. New registrations will be set to our name servers. All bulk registrations and transfers use the account contact information of the account used to pay for the domain (unless you select "private"). If you want custom contact information or name servers, we can process that as long as you have 10 or more domain names with the same settings.
There are no bulk discounts; we give everybody the best possible price on domain. But, if you have a lot of domains to manage, this feature can make the process significantly easier for you. Please contact us if you have any questions about it.
Click "Manage" in the "Registrar" column for your domain name.
Click the "Renew This Domain" action.
Select the number of years you want to add.
Click the "Renew Domain" button.
Review the summary to make sure it is correct.
Click the "Renew Now" button.
Click "Manage" in the "Registrar" column for your domain name.
Use the "Lock Domain" action to protect you from domain hijacking.
If your domain is registered with us and it is set to auto-renew, it will renew automatically for another year about a week before expiration with no action needed on your part, provided there are sufficient funds in your account. (You'll be warned repeatedly and often if the necessary funds are not available.)
If your domain is not registered through us, you will need to contact your registrar to renew it.
Remember, any renewals add on to the existing registration. So if it is May 2023 and your domain expires in August 2023 and you purchase a one year renewal, your new expiration date will be in August 2024, not May 2024. There is no penalty for renewing early!
Regardless of the renewal method, the maximum length of time on a domain registration is ten years from today. Thus, if your domain expires in five years and a few days (for example, if today is February 16, 2017 and your domain expires on February 21, 2022) you'll only be able to renew it for a maximum of four more years, because it can't be renewed for a partial additional year. Our system won't let you select a number of years for renewal that exceeds the allowed maximum of ten. (This also means that for a domain that expires in more than nine but less than ten years, our system won't let you attempt to renew it at all.)
When you perform a transfer to another registrar, they will send you a confirmation message. If you approve the transfer on their side but take no further action, the transfer will complete by default after about seven days. However, after you approve the transfer with your new registrar, our registrar will also send you a confirmation message that should allow you to approve or decline the transfer. If you approve the transfer there as well, it should complete much more quickly.
In most cases, transferring a domain near to or shortly after its expiration will not result in any problems or disruption in service; each TLD is managed through a central registry and their systems are smart enough to recognize that the domain has been renewed, even if it's through a different registrar. However, not all registrar's systems are capable of processing the transfer of expired domains, so even though it will probably be fine, to avoid the consequences of probably, we always recommend that you manage any transfers well in advance of domain expiration. If you encounter a problem with the transfer of an expired domain, we will probably be unable to help.
You'll have to get most of the specifics about this from the registrar you're transferring the domain to, as their system will coordinate most of the transfer and they will have the best information about how their system works.
However, here's some general information about the process that may help.
First, you should do some "preflight checks:"
Make sure the domain is currently registered here. (If it is, it will have "Manage" in the "Registrar" column on the Domains tab.)
Make sure you have not registered, renewed or transferred the domain recently. ICANN rules impose a 60-day waiting period after a previous registration or transfer. If you transfer a domain within 45 days of a previous renewal, it may succeed, but you risk losing the renewal years you paid for without a refund.
Make sure the domain is not too expired. Domains can be transferred after expiration as long as they remain in the renewal grace period, but not once they enter any redemption status, including: queued for deletion, pending delete restorable, or pending delete.
Make sure your domain's contact information is valid. The administrative contact will be emailed twice during the transfer process. Note that if you have RespectMyPrivacy, do not cancel it before transferring your domain. It will forward the messages to you, and it will drop off automatically when the transfer finalizes.
Once you've confirmed the domain is ready to transfer, the steps of the transfer will be more or less as follows:
If your domain is locked (which it ordinarily should be), go to the Registration Info Panel and select "Unlock Domain" in the Actions box.
Retrieve the transfer code. (The registrar you are transferring to may call this the EPP code or the auth info code. All three terms refer to the same thing.)
Place the transfer order with your new registrar.
Your new registrar will send the domain's registrant contact an approval message. This message will contain a link that must be clicked, or similar steps to confirm that it was received and that the administrative contact wants the domain transferred.
Our registrar will send the registrant contact a message with a link you can use to cancel the transfer if you want. Don't click the link. (Unless you want to cancel the transfer.) Most of the time this email will also have an approval link you can use to expedite the transfer.
If you don't have (or don't use) an approval link, wait about seven days. If your domain was less than seven days from expiring when you started the transfer, don't worry. It's not ideal to wait until the last minute, but it usually does not cause any disruption.
Once the transfer completes, the registration and RespectMyPrivacy (if applicable) will drop off, but if it has DNS, email forwarding, or is used for aliases, those will continue to exist. If you aren't using them anymore, you can remove those manually once you're sure doing so won't cause any interruptions.
The complete list of top-level domains (TLDs) in which we can provide domain registration services (including new registrations, renewals, and transfers) can be found on this page.
Currently we offer only generic top-level domains (gTLDs) and the .us ccTLD. If you want to register a domain in another country's top-level domain (ccTLD), you will need to contact a registrar accredited by that country. Although some countries have chosen to market them otherwise, all two-letter TLDs are ccTLDs.
If you already have such a domain and wish to use it with our service, this is generally no problem. Just add your domain to our control panel as an existing domain, create DNS for it, and have your registrar update your name server information accordingly.
When you renew a domain, the renewal period begins at the end of the current registration period. In other words, renewing for one year adds one year to the current expiration date, even if the current expiration date is months (or years) away.
Exception: Your domain can never be registered for more than ten years. So if a domain's current expiration date is 9.5 years away, our system will return the error "this domain is already registered for the maximum duration" and not allow a renewal attempt. You'd need to wait until a full additional year could be added before you'd be able to renew it.
Please don't wait until the last possible minute to renew (or transfer) your domain.
Our domain registration services are provided under the auspices of a third-party company, Public Domain Registry. They are required by the various top-level domain registries and ICANN to impose various conditions on registration.
Public Domain Registry also resells web hosting and other services using a product they call "OrderBox." We are not resellers of the "OrderBox" services. They have a laundry list of terms and conditions for the use of those services that can be found in "Appendix A" of their Registrar-Registrant agreement, which you must agree to in order to register domain names through us.
Unlike our own Terms and Conditions of Service, theirs are fairly typical for the hosting industry, including a variety of prohibitions against controversial behavior that are highly inconsistent with our own. The contents of their "Appendix A" do not apply to your use of our hosting services.
The enforceability of their agreement is strictly limited to your use of their domain registration service. "Appendix A" applies to your use of their hosting (or other) services. Since you are using our hosting services, not theirs, its prohibitions are irrelevant to you and are superceded by our own Terms and Conditions of Service. Public Domain Registry has no authority or ability to interfere with your NearlyFreeSpeech.NET hosting services. No matter what you do, their sole remedy would be refusal to process your domain registration.*
To look at it another way, since we do not provide those services, you are not allowed to use their "OrderBox Services" at all, so the question of how you may use them is moot. It's unfortunate that they have chosen this "everything and the kitchen sink" approach to their agreement, but they did.
If you register a domain with an offensive or controversial component, you are at a certain level of risk of having your domain cancelled, but typically not from Public Domain Registry. Each top-level domain registry has different rules for what domain names they will allow, and no matter what registrar you choose, you will always be subject to those rules.
If this is a concern to you, do not register a domain name (anywhere) containing an offensive or controversial component.
Invalid or "private" administrative contact information.
Not responding to the transfer approval email sent to the administrative contact address.
Trying to transfer the domain within 60 days of a registrant change or a previous renewal, registration, or transfer.
You owe the domain registrar money.
If you are transferring from another registrar to us, the other registrar is not required to give us a reason for refusing a transfer, so if the problem is anything other than "the administrative contact did not confirm the transfer," we won't be able to provide you with any information.
When domains expire, the registrar shifts the domain's name servers to special "parked" nameservers. As soon as the domain is renewed, the name servers are switched back. However, the global registries serve 2-day time-to-live (TTL) values when delivering name server glue records.
This means that most people who haven't already seen the "parked" domain will be able to see the site after it's renewed. However, anyone who tried to access the domain while it was expired (including, most likely, you -- its registrant) may continue to see the "parked" page until the two-day time-to-live period expires. It is possible to see the exact remaining time with the Unix command line utility dig, if it is present on your local system.
Although this doesn't tend to affect most site visitors, those who are affected have no recourse unless they have direct control over their local name servers. This is standard to the global registries that operate each TLD and thus works exactly the same for all registrars. It is not something we or our registrar chose or have control over.
In order to prevent this, NearlyFreeSpeech.NET recommends that you either use our auto-renewal feature to make sure your domain never expires or pre-renew your domain so it is never within a year of expiring.
External domains are those domains which are registered through some other company that are not eligible be transferred in to our service. This typically includes domains in top-level domains that we do not support for registration, such as all ccTLDs.
On the next page, tell us more about the domain you want to register:
Enter your desired domain name in the "Name To Register" field; for example if you wanted to register example.com, you'd enter just "example" (without quotes).
Choose the top-level domain (TLD), such as .com or .net from the provided menu. All of the TLDs we support are listed in that menu.
Select the number of years for which you'd like to register the domain, up to a maximum of 10.
Once you've verified that your information is correct, use the "Add Domain" button to proceed to the next page.
Next, choose whether to use your own contact information or our RespectMyPrivacy service:
If you want to use RespectMyPrivacy, just select it using the button next to "I want RespectMyPrivacy.COM Proxy Contacts." You won't be asked to enter any contact information during the registration process.
If you want to use your own contact information, choose "I will enter my own contact information." If you've never entered contact information before, the next page will present you with an explanation and the "Add a New Contact" button and you'll be taken to a form that is prepopulated with your account information, which you can edit if necessary. (This won't affect the contact information as it is listed on your account with us.) Once that step is done, or if you already have other registered domains with us, you'll be presented with a list of contact types and corresponding menus that contain any previous sets of contacts you've submitted, and the option to edit the selected registrant contact's information or create a new contact instead if you like.
After you've chosen your contact type and done any needed additions or editing, continue to the page that lets you choose how you want to set up your DNS:
Choosing "set up DNS and name servers automatically" will tell our system to enable our DNS service for this domain and add relevant name servers to the registration;
Choosing "I want to specify my own name servers" will take you to a form that allows you to enter them.
Once you've completed the setup of your DNS, the final page of the process shows you the information you've entered and gives you an opportunity to complete the registration. If you see something that's amiss, you can start over, but be sure to use the "Start Over" button; you might get unexpected results if you use your browser's back button.
When all of this is done correctly, you'll receive a page confirming that you've successfully registered the domain.
This means that at some point, you set your domain registration to be renewed manually; to renew it, see this FAQ entry.
Our system won't automatically use the funds you deposit to renew any domain registration not set to "Auto Renew." To view (or change) this setting for a domain registered through us:
Select the "Manage" button next to the relevant domain name to go to the Registration Details panel for that domain. (If the button next to the domain name says "Transfer" instead of "Manage," then it isn't registered through us.)
In the "Registration Details" box, on the "Renewal Type" line, you can see the domain's renewal type ("Manual Renew," "Auto Renew," or "Do Not Renew").
Use the Edit button on that same line to change the renewal type if you wish.
If a domain isn't registered through us, you will have to contact your registrar to renew it, or transfer it to us, which generally includes a one-year renewal.
When the registry interface we use returns an error, the error messages are usually neither human nor machine readable, so we sometimes have to mask them with this message.
Here are some of the most common reasons this can happen:
Any kind of punctuation in your name, even if it belongs there. (e.g. O'Malley)
Non-ASCII characters in your name or address. (This particularly afflicts members from Scandinavia.)
Anything but 4-12 digits in your phone number. (Write it as 2125551212.)
If you've followed all these restrictions and you still can't figure out what the problem is, we do have a way to look up the error and decode it by hand. You can ask for a lookup via our forum or (if you have a subscription membership) support issue.
Just visit the Domains panel, and, under the "Registrar" column in the domains list, select the "Manage" button for the relevant domain to view its "Registration Details" page. In the "Actions" box on that page, you'll find an "Edit Renewal Type" option. Set this to "Do Not Renew" and our system will stop telling you about your expiring/expired domain.
If you decide to use RespectMyPrivacy when you register a domain, it can be enabled during the second step of the process. It becomes active at the time the registration is completed, which keeps your information from ever being exposed in the WHOIS database when you register your domain.
If you want to add it to domain that is already registered, see this entry.
Domains cannot be re-renewed immediately after they have been renewed; to prevent accidental double-renewal orders from getting placed they are locked out for a period of time. During that time, they won't show up in the renewal monitor.
Recently-renewed domains should reappear on the renewal monitor within a few hours. Until they do, you can still view and edit them as normal on the Domains panel and their individual "Registration Details" pages.
The unique link you receive via email when you approve or cancel a domain transfer or verify a domain contact is only valid once. If it's already been accessed for any reason, you will receive the (incredibly unhelpful) error message "Invalid URL." This message/page is not generated by us and we have no control over its content.
If you encounter "Invalid URL" by surprise, usually this means one of two things has happened. Either your email client has "helpfully" prefetched the URL, or, most frequently, you double-clicked the link in the email causing it to load twice. In both cases, the action you're verifying is already done.
If you're transferring a domain to us and you get this from the approval link, this means the transfer is approved and you can confirm this by going to the domain's info panel in our member interface (select "Manage" in the "Registrar" column for the domain on the Domains panel) and confirming the Action status is "Transfer waiting for Losing Registrar Approval." Likewise, if you get it from the cancel link, the domain transfer is already pending cancel and should be killed and refunded within a few hours.
If you are transferring a domain away from us, this means the transfer will be blocked.
If you're approving a contact, this means the contact is approved and that status should reflect in our UI within an hour.
If you receive this message and whatever you're doing doesn't show up as successful (i.e. the Action status is still "waiting for admin contact approval" or the domain still shows as unverified after an hour) then it's also possible your email client may be breaking up or mangling the URL. Check to make sure it hasn't split the URL onto multiple lines, possibly adding a character at the end of the first line.
Yes, although currently the process is manual and carries a nominal fee unless you have a subscription membership. DS records can be loaded to or removed from the registry through our assistance request system.
If you have RespectMyPrivacy service on your domain, you need only update the contact information on the Account Information panel for your account. The public WHOIS database will always display RespectMyPrivacy's contact information.
If you do not use privacy service, our registrar makes it a two-step process to update domain contact information: first, you create a contact then, second, you apply a contact to a domain in one or more roles.
If your new contact resembles an existing one (e.g. you're just changing a phone number or email address), click "Edit Copy" next to the closest existing contact. Otherwise use the "Add a New Contact" button at the bottom of the page.
Fill out all the required information on the "Edit Registration Contact" page.
ccTLDs are the two-letter TLDs assigned to individual countries based on their ISO country code, like .us, .uk or .de. All two-letter TLDs are ccTLDs, even though some (like .me and .ai) are marketed otherwise.
We are very hesitant to allow adding ccTLDs for countries other than the United States. Doing so raises concerns about giving those countries political, economic, or legal leverage over us or our members. Most ccTLD operators are part of or run on behalf of the country's government. They typically include things in their registrar agreement like "Paragraph 1219: You will follow all of our country's laws." and "Paragraph 2751: The ccTLD operator reserves the right to terminate this agreement at any time for any reason." That's a problem.
For example, suppose that we offered registrations in Atlantis's ccTLD and accumulated a few thousand domains. And maybe the Atlantis government decides they don't like a site we host that criticizes their land subsidence policies. Next thing we know, they're threatening to seize all those domains unless we cut somebody off, and claiming that we agreed to follow their laws on such matters.
While that may sound farfetched, we have had conflicts with foreign governments over member sites, and they don't play nice. Handing significant leverage to people who may not have our members' best interests at heart doesn't seem like a good idea.
Many ccTLD's also have weird, special requirements and procedures that would require a lot of extra work for us to support. (Looking right at you, .uk, and your IPS tags!) That may not sound like a big deal, but "extra work" for us translates directly to "extra cost" for you. Some ccTLDs even have complex legal requirements that the registrar, the name servers, or the registrant be physically present in that country that would be difficult or impossible for us to meet, even if all the other issues didn't exist.
If you are a subscription member, we may be able to manually register or transfer a domain for you from a gTLD that is not on our regular list. To be eligible for manual registration, these criteria apply:
You must have an active subscription membership.
The domain must be in a gTLD. ccTLDs are not eligible.
The gTLD must be supported by our registrar. (Ask us to check this, either via a support issue or on the forum.)
The gTLD must not have any nonstandard implementation requirements or verifications. (Professional gTLDs like .LAWYER often run afoul of this.)
To request a manual registration as a subscription member, open a support issue.
If you are interested in a manual registration but are not a subscription member, we recommend asking about the gTLD in our forum before upgrading to a subscription membership.
As an anti-spam provision, each web site has a dynamic email limit called its "email bank." This represents the amount of email that a site can send before it is rate-limited. By default, the email bank can hold a maximum of 100 "points," each of which can be used to send one message. Points accrue at the rate of one per minute, starting from 0 when the site is created.
Each site's email bank values are shown on the Site Information page as a fraction on the "Email Sending" line. The first number indicates the current size of the email bank, and the second number indicates the maximum size. For example, if it shows 75/100, it means the site's email bank currently contains 75 out of a maximum of 100 points. If it shows 100/100, it indicates that your bank is full, implying that the site has not sent any email recently.
Each time your site sends a message, the email bank will be debited one point. As long as your site's current email bank size is positive, it should be able to send 30-60 messages per minute. If your site's email bank reaches zero (e.g. 0/100), additional messages sent will be queued until more points are available, effectively rate-limiting additional messages to one per minute. If your site has queued outbound messages, this information will also be visible on the Site Information page.
If a message bounces or is blocked by our outbound spam filters or for noncompliance with best practices, then an additional point will be debited from the bank.
You can see information about your email bank, current queue size (if any), and counts of messages sent, bounced, or dropped (in the format today/yesterday) on the Site Information panel for your site.
If your site generates a large mail queue, usually the result of a vulnerable email form, we will automatically investigate. If we believe there is an issue, we will remove spam, disable any exploited sites, and contact you about the problem.
If the messages are not spam, they will be cleared to send, and if it happens frequently, your maximum bank size may be raised to accommodate the typical volume of email that your site sends. If you have an increased bank size, you will both send messages and recover bank points more quickly. We do not make changes to the automatic email volume limits based on member inquiry, only based on actual, reoccurring conditions detected and observed by us. Most reviews of the queue take place during our standard support hours, so if you have a large volume of mail to send, please try to avoid sending it in the middle of the night or it may get delayed until the following morning.
The email bank and sending/bounce/drop statistics apply only to emails sent by your web site. Email forwarding is an entirely separate service and has no connection to any site's email bank.
We do not currently offer email hosting, nor do we offer any reseller arrangements in this area at the present time.
Some of the paid services that people have recommended include FastMail, and Google Workspace. But it's not lost on us that this list is getting short. We've had to remove entries from this list more often than we've been able to add them. Please choose your email provider carefully.
Our theory is that Gmail does not like "duplicate" messages. Because there is a copy of this message already in your "Sent" folder, it appears that gmail will ignore the copy that has made the round trip through our server and back.
If you try your test from some other Gmail account (one other than the one the message will ultimately be delivered to) then it should arrive normally.
Gmail also filters spam and viruses fairly vigorously, and sometimes test messages blend in, so don't forget to check your "Junk" folder if you're expecting a message that hasn't arrived. We also have some reported cases that messages sent to Gmail sometimes simply don't arrive (whether forwarded through our system or not).
This is one of the great scourges facing the Internet today. Anyone can forge email to make it look like it came from anyone, and spammers do. They don't need anything special, no passwords, no special access, nothing. They pick domains at random in order to help obscure who they are and where they are coming from.
If this happens to your domain, the symptom will be that you will receive a large number of bounce messages for messages you never sent. If you investigate further, you will generally find that the From: addresses of the messages are either fake names (frank@example.com, bob@example.com) or gibberish addresses (2nkdklwejw@example.com).
When you configure your mail client to send mail from your domain instead of your ISP's, it's completely between you and your mail client. Everybody else has to trust that you told your software the truth. Nobody can stop you from putting "president@whitehouse.gov" as your sender address. Spammers abuse this trust to send out their messages.
Messages like these never pass through our system, so we can't help you figure out where they are coming from or help stop them. In general, messages of this type are sent through hacked machines belonging to residential cable modem Internet subscribers, or they are sent through unprotected servers in developing countries like China.
This happens sooner or later with every registered domain and, at present, there is unfortunately nothing that can be done to stop it. This is true no matter what domain registrar or hosting company is used, and is even true if the domain isn't used for web hosting.
If you use your domain for email, setting an SPF record in your DNS that lists servers that legitimately originate email from your domain may help. We do offer an SPF option for domains not used for sending email, which is a helpful step if it applies.
While you cannot prevent this from happening, you can diminish its effects on you. Most of the people who get buried in bounce messages have "catch-all" email forwarding enabled. You can disable this and set up only specific email forwards, and this will dramatically decrease the number of bogus bounce messages you receive.
If you prefer a free, web-based solution, Gmail is one of the most popular, although some of our members find trusting Google with such sensitive information difficult. However, it can be tricky to get Gmail to send email from a non-Gmail address and Google is slowly removing the options for doing so.
In addition, most mail programs, such as Outlook, Outlook Express, and Thunderbird, have the ability to do this with just a few minutes' worth of configuration. However, you must have an SMTP email server that you can use to send these messages; we do not provide that service.
In almost all cases, the SMTP server you should use to send mail from your domain is run by your ISP, and it is the same server you would use to send mail from your regular ISP email account. Since ISPs vary widely, we cannot provide more specific guidance than this. However, they should have their own technical support that can help you get this set up.
For many reasons, we cannot provide this service to you. Most ISPs block access to outside mail servers by their users because of the email problems created when one of their users' computers gets a virus. Even if yours doesn't (and they probably should), you cannot use our servers to send mail as this is a technique called "relaying" that is used by spammers to conceal the origin of their messages. As a result of that, the practice of relaying is now deprecated and is not supported.
In order to fight spam, our email servers have very high standards for accepting email. Occasionally, this may cause someone who wants to send you email from a misconfigured email server to run into problems. If you can get a copy of the bounce message and forward it to us, we may be able to point the server operators in the right direction as far as fixing their problem, but since it is their problem, it will be up to them to fix it.
Since most of the inquiries about this come from people who are not members but have email problems and don't know what to do about them, most of our documentation of this subject can be found on our public Email Acceptance policy page in an attempt to help them.
We need you to have a current, working email address at all times in case we need to contact you about problems. If anything important to your contact email address is hosted here (DNS, domain registration, or email forwarding) and there's a problem with your service, we might not be able to contact you. That's bad.
For example, suppose your domain is registered here and it expires. And suppose that you forgot your password and need a new one mailed to you to fix things. But you can't get that message because your email doesn't work when your domain is expired. In cases like that, our Privacy Policy turns from a critically-important protection into a colossal roadblock; you'll wind up giving us a DNA sample and fingerprints to get your access back. (Well, not really, but it'll feel like that, especially if you're in a hurry.)
These types of circular dependencies create a lot of headaches, so we simply don't allow them.
If you don't want to have multiple email boxes to keep track of, there is a workaround. If your primary email address is in the domain that you want to host here, you can create a special alternate email address somewhere else, for example at a reasonably reliable provider of free email accounts, and set it up to forward copies of all the messages it receives to your normal mailbox. That way, you'll get all the messages, but if there's ever a problem, you can fall back on the alternate mailbox, secure in the knowledge that it's got copies of any recent messages we've sent you to work from.
Just be sure that you don't need your primary email address to reset your alternate one, in case you forget both. A bigger circular dependency is still a circular dependency. Whatever setup of forwarding and responsibility you set up should be able to be represented with a directed acyclic dependency graph.
If you want to originate mail from your site that uses a sender address in a domain name of yours, to help prevent your messages from being marked as spam, you should publish an SPF record incorporating our sending servers. This can be easily done without the need to check for periodic updates by using the SPF include facility. Just add include:sites.nearlyfreespeech.net to your SPF record.
For example, if you send email from your site, such as forum registrations from forum@example.com, but most of example.com's email is handled by Google apps, you would add a TXT record for example.com like:
This will tell the world that mail from example.com may originate from either Google or our sending servers, and that anything that comes from elsewhere is probably (but not definitely) a forgery.
Because of the very different usages and sending profiles, we have three completely different sets of email servers: one for NearlyFreeSpeech.NET service-related email, another for email forwarding, and a third for mail originating from member sites. Thus it is very important that you do not put include:nearlyfreespeech.net in your SPF record. We also strongly recommend against hardcoding specific servers into your SPF records. We may change them from time to time without notice.
If your site runs PHP, you should use the mail() function.
For all other languages, you should use /usr/bin/sendmail.
These are the only supported methods to send email from sites hosted on our service.
You may not connect to SMTP ports 25 or 465 on other networks' servers; these are SMTP MTA (mail transfer agent) ports used by full-time email servers to exchange existing messages with each other. Your web site is not an email server, so it is not appropriate for it to use these ports. Therefore, to prevent spammers from abusing our service, we actively block such connections.
Some email services offer authenticated SMTP MSA (mail submission agent) services on port 587 that may be appropriate for accepting new email messages from your site. However, doing so is unsupported by us and we do not guarantee it will be a suitable option for your circumstances; contact your email service if you need any assistance with this.
Greylisting is a technique we use in conjunction with email forwarding designed to help differentiate misconfigured servers from spammers and virus-writers.
A variety of standards and best practices exist around the protocols used to send emails and identify their senders (SMTP and DNS). Most servers follow these standards very closely. Spammers and email virus writers, on the other hand, are just as uninterested in standards as they are in the laws against what they do.
If (and only if) a standards compliance problem is detected with a sending server, the message it's sending is refused by us, and the sending server is added to the greylist. If the server tries to send that same message again a little later (one to four hours, depending on how messed up the server is), the message will be allowed and that server will be automatically added to a whitelist of servers that have passed the test.
Legitimate mail servers are required to queue messages and try them again later, so to them greylisting is a temporary inconvenience (plus it puts messages in their logs telling them to fix whatever problem(s) got them on the list). Viruses, on the other hand, have to fit their SMTP engines into small spaces; even if they wanted to implement a system that retried messages, they typically have no place to queue them. Greylisting is thus very effective against viruses in general, even new viruses that standard virus scans don't know to detect. Spam senders are somewhere in the middle; many use poorly-written software that simply sends out as much as it can as fast as it can, ignoring errors, and greylisting can be a pretty effective barrier to those.
The greylist (and the associated auto-whitelist) is on a per-sending-server basis and is shared by all of our email forwarding domains. Once auto-whitelisted, a legitimate server stays there until it goes 32 days without sending any mail; every time a message goes through, the clock resets. So as long as a server sends a message to someone using our email forwarding service at least once per month, it will stay in the clear.
In the event of a conflict, the spam blacklist (a list of known spam sources) overrides the auto-whitelist, so if a sending server is identified as a spam source sometime after being auto-whitelisted, its messages will still be thwarted.
The defining characteristic of any email forwarding service is that it forwards the email it receives on your behalf to some other mail server. When it comes to spam, this is a problem.
If we forward spam to other mail servers, those other mail servers don't know we didn't originate it. ("Hey, I really got this message from that other guy!" is a common spam sender trick.) If we forward enough of it, they will assume we are spammers and block our forwarders from delivering email to their mail servers entirely. Doing our best to prevent spam is the only way we can assure our continued ability to provide this service.
For that reason, we cannot honor requests to bypass our filtering mechanisms under any circumstances. To do so would threaten not only our ability to forward email to the member requesting it, but also our ability to forward email at all.
This is an unfortunate circumstance, but it's a necessary evil and is true for all viable email forwarding services, not just ours. If you have some special circumstance that requires you to receive spam, spam-like email, or viruses, or if you simply want to exert maximum control over how your email is handled, you will need to eschew the use of any type of forwarding and arrange for a direct-delivery email service that provides that level of control.
NearlyFreeSpeech.NET is a do-it-yourself service, designed to allow experienced webmasters and people who are strongly self-motivated to set up low-cost hosting by only paying for services they actually use.
Support is a great example of a high-cost service that's typically bundled into hosting offerings. But it's also a great example of a service that most of our members don't use and don't want to pay for. As a result, our system is designed to be used without individual private support, and our baseline membership does not provide it. Nor do we offer "pre-sales" support; it's up to you to figure out if our service is a good fit for your needs. (Meaning that if you email us almost any question prior to signing up, there's no one here being paid to answer that, so you're going to get a link to this FAQ entry in reply.)
If you do want support, we do provide a wealth of documentation, self-support and community-support options. There is also a higher-cost subscription membership available that offers limited individual private support via email and our website. But this doesn't change the do-it-yourself nature of our service: individual support provided to subscription members is limited to guidance, you'll still have to do all of the heavy lifting yourself.
This means that if you don't want to pay for individual private support, you don't have to. But it also means that if you don't pay for it, you won't get it.
If one of those options works for you, great! If, on the other hand, you're looking for a more "high contact" approach to support or if you're looking for someone to create or manage a site for you, that's absolutely fine, but a do-it-yourself service like ours may not be the best fit for your needs.
To put it another way, some people change their own oil. Some people pay a mechanic to do it because although they could do it themselves, they want to spend their time another way. And some people pay a mechanic to do it because they just want their car to work and the details don't interest them. NearlyFreeSpeech.NET is a service for people who want to change their web site's oil.
The most common mistake people make while signing up for our service is disregarding the unique one-to-one relationship between a person and their membership.
Your membership represents you as an individual. As it says in bold print on our signup page, you may only have one membership, you may not create a membership for anyone but yourself, no one but you may access your membership, you can't transfer your membership to another person. (Transferring some or all of the services on your membership to another member, on the other hand, is dead easy. So is sharing things if you have more than one person who needs to be involved.) You must also use your individual, real name on your membership.
These warnings and policies are there for a reason. When people don't follow them, then sooner or later problems result.
Don't: create memberships for other people.
Do: host their stuff for them on your membership or get them to do it themselves.
Don't: tell us your real name is "Company Inc." or "Organization Webmaster."
Do: create an account for the organization on your membership.
Don't: create a second membership for a new project or customer you want to work on.
Do: create a second account instead.
Don't: give your login credentials to somebody so they can help you or share responsibility.
Do: have them create their own membership and give them adjunct access to your site or
share your account with them.
Basically, all we ask is that you don't pretend to be someone else. If you do, it will eventually result in problems. You may find yourself unable to log in, unable to make payments, or your membership may wind up in the hands of someone who has no idea what they're doing. Those problems are fixable (as long as the person whose name is on the membership is still around) but it's pretty certain they won't crop up on a day when you've got plenty of spare time and nothing better to do.
We don't have very many rules, but providing your real/legal name on your membership is one of them, and we do take it seriously.
If you lose access to your membership, the first step in our recovery process is providing a government-issued photo ID matching the name on the membership. For that to work, we need your legal name. If you entered a fake name or an organization name or "Thus-and-such Webmaster" when you signed up, you're typically screwed.
If you real name and legal name differ, we ask for both. We'll set the legal name aside for ID verification and use your real name for all other purposes.
We're absolutely fanatical about our privacy policy. We won't give your name to anybody unless somebody shows up with a judge's signature. In some cases, not even then. If you don't trust us with your name, you probably shouldn't trust us with your content.
If you sign up with a name that isn't a person (i.e., a club/company/organization/role name), or if we have any other reason to believe you've given a false name, we will ask you to fix it. If you refuse, we'll ask you to show a photo ID matching the name you provided (if we're not sure). If you don't, we may be forced to suspend your ability to make further deposits and eventually terminate your service.
If you are an existing member who has given us an incorrect name, please see this entry in the Member FAQ to fix it before it's too late.
Maybe. We aren’t out to provide the cheapest possible service. In fact, we have absolutely no interest in doing so. Our goal to is to provide a high-quality service at a fair price, and make it scale so we can put that service in the hands of as many people as possible, many of whom couldn't otherwise afford it.
With that said, the most common reason people feel that we're more expensive than an alternative is that they are comparing us to a different type of service.
We provide a fully managed environment, including frequent security updates, careful performance tuning, and 24x7 response to crashes and outages for everything underneath your code. The tools you need to build your site are already there, ready to be used and customized however you want. We have dedicated infrastructure to build a constant stream of updates, more infrastructure that runs regression tests on those updates to make sure things are working before they get to you, then we let you pick just how aggressively you want those updates applied.
With an unmanaged VPS, the provider maintains the hardware (hopefully), but doesn’t care if your VPS is up or down. The full responsibility of installing and maintaining the OS, the system configuration, all the packages and utilities, and the entire application stack falls on you. Every critical security update. Every urgent kernel patch. Every weird error in the system log. Every crash in the middle of the night. Every traffic surge. You have to know about it, you have to know what to do about it, and you have to do it. Often on a deadline. And that responsibility never goes away. It never even takes a day off.
Occasionally, people comparing us to a VPS zero-value that, because it hasn't occurred to them, or because they plan to do it themselves (some of it, anyway — system administration is a well-paying full-time job) and haven’t placed a dollar value on their time. But VPS providers sure don't zero-value it. The price difference between an unmanaged VPS and a fully-managed VPS from the same provider is often $50-200/month. Already, our pricing looks a lot better!
Second, the lowest VPS deals come from brand new providers who lose money on every sale. They’re buying market share by selling below their cost. We don’t compete with them on price. We just wait for them to go out of business.
Third, VPS providers use all sorts of tricks to make it seem like they’re providing a lot more than they really are. Hopefully you’re already convinced, but if you’re in the mood to keep reading, the rest of this FAQ entry contains a partial (but long) list of such tricks and what we do differently.
VPSs and RAM:
A fair bit of the RAM in a VPS goes to the kernel. Behind the scenes, providers use a technique called memory deduplication to sell the same memory to 100+ VPS customers on a single machine. We don't charge you for kernel memory at all.
If you want your application to perform well, you'll need a fair amount of memory for disk cache. For a nontrivial application, usually 25% or so of the total memory, although the system will always try to use as much as it can. With a VPS, that comes out of the RAM you're paying for. At NearlyFreeSpeech.NET, it does not.
The memory a VPS provides you is a limit. You can't exceed it. If your VPS runs out of RAM, when you get a surge of activity, it won’t be able to scale and may as well be down. That means you have to pay for the most memory you'll ever need to handle the highest load you anticipate ever having. The other 99% of the time, you're still paying for all that RAM, but it's sitting there unused. We charge you for the memory you’re using right now. If you need more, it’ll be there, if you need less, you don’t pay for what you’re not using.
VPSs and storage space
Modern filesystems require at least 15-30% slack space to perform well, so that comes right off the top of a VPSs storage allocation. We only charge for the space you're actually, currently using. If you delete files, your bill goes down.
Then you install the whole OS into it, eating up even more. (And in the background, they quietly deduplicate that too, so they can sell the same disk space over and over.) We don't charge you for the space used by the OS, the system tools, utilities, and development tools (or the entire application stack, if you use one of the ones we provide, like PHP).
You have to leave room for growth. It's not unusual to see a VPS with only 10-15% of its allocated disk space actually used by application data. Here, the space will be there if you need it, but there’s no need to pay for it until you do, or after you’re done with it.
VPS storage usually isn't backed up by default. That costs extra and is often a "last backup only" approach. Our storage pricing for sites includes extensive, frequent snapshots and backups — onsite and offsite — at no additional charge. (If you need a restore performed, that takes a human, so there is usually a small charge for that at that time.)
At most providers, storage is directly connected to the machine hosting a VPS. That's good for performance, but not so good for reliability. If the machine hosting a VPS dies, well, see above about backups. We use redundant network storage built entirely from SSDs with no single point of failure for all member sites and MySQL data.
VPS overselling
VPSs often measure CPU based on “virtual” CPU cores (“vCPUs”). As with RAM, there are a lot more “vCPUs” in VPSs than there are actual CPUs in the machine running them. If too many people try to use them at once, things slow way down, and there’s usually no way for you to figure out why. With us, most sites don’t pay for CPU at all, but those that do pay only for what they’re actually using at that moment.
VPS providers rarely support live migration. If you’re on a heavily-loaded server (or the server crashes) at a cheap VPS provider, tough luck. Decent providers will tell you a server is overloaded and offer to move you, but without live migration, that means a long downtime while they copy your disk images around. NearlyFreeSpeech.NET uses dynamic load balancing directly informed in real time by the same resource metrics used for billing. If a server gets overloaded here, load automatically shifts. If it’s still (or very) overloaded, somebody gets paged to check it out or allocate extra hardware for it if needed. If a server goes down, affected sites automatically migrate to other servers within about 60 seconds.
Check the VPS provider’s Terms of Service for words like “excessive resource usage.” If you find them, it’s often code for “if you actually try to use what you paid for for any length of time, we will promptly put a stop to that.” Here, charging only for the resources we actually provide creates a financial incentive for overprovisioning instead of overselling.
We are not trying to say all VPSs are bad, or even that they’re all a bad deal. There are some applications where a VPS is a better fit than our service. And if you don’t need or want all that we provide, and don’t mind doing a lot of work yourself, a low-end VPS may save you some money. But in an awful lot of cases, for sites big and small, we provide an excellent value that no VPS can match.
We do, however, provide email forwarding service. You can set up as many different addresses at your domain as you like, specifying where each one should be forwarded and/or use "catchall" forwarding to send everything to a single address.
This service only handles inbound mail, and only forwards it. You will have to make other arrangements for a mailbox to receive the messages, and to send outbound mail.
For that, the first choice, and often the best one, is to use the email account(s) provided by your ISP for this, but there are other options. Many of our members choose to use email services like
Gmail or whatever Microsoft is calling their email this week.
Compared to the endless parade of hosts that provide tons of "one-click installs," one-size-fits-all web site templates, unlimited toll-free telephone support, and cookie-cutter control panels, our service is arcane and complex. We consider this a positive.
Our service is designed for people who are comfortable with Unix-based web hosting, including manipulating MySQL and files using command line tools. To get good results for nontrivial sites, our members need to understand how Unix file permissions and ownership work, and how they apply to a secure web hosting environment.
We do provide extensive documentation, including a massive FAQ, that addresses a large number of the most common inquiries we receive. Because we employ neither "canned answers" to inquiries for support nor underpaid "tier 1" support personnel to give them, we do tend to refer people to the documentation when their questions have detailed and complete answers there.
But if our systems are working properly, we expect that most of our members should never need to contact support. By extension, they should not have to pay extra to maintain a staff of people they never use. Consequently, our free technical support is extremely limited and is provided primarily through our community forum. The primary option for those seeking individual support (subscription membership) costs extra and even that has fairly strict limits as far as how much help we can provide.
We have found that most of our successful members are those who have previous experience with web hosting. This is, however, a gross generalization. We have plenty of members who have made amazing sites starting from ground zero because they are strongly self-motivated and learn well independently. It's cool for us to watch them learn, too.
If you are not comfortable that you already have the knowledge and experience outlined here, and you do not particularly want to acquire it, that's a perfectly valid position, but it means that using our service may be an exercise in frustration for you that is best avoided.
Yes! Our DNS service meets most simple DNS and email service requirements for the average website. NearlyFreeSpeech.NET DNS supports most common resource record types (A, AAAA, CNAME, MX, NS, SRV, TXT, and PTR).
Our system is very flexible in this regard. Each membership can have one or more accounts. Each account can have one or more sites. Each site can have one or more domain names. For many people, this means one membership, one account, one site, and one domain name. For many others, it gives them the power to be as creative as they want, and to pursue several different goals.
Whether you spread your websites across multiple accounts or keep them all in one is completely up to you. Support for multiple accounts allows people who have sites for different reasons, such as business and personal, to keep the finances separate if they choose to do so.
Our system will send you email (or, optionally, SMS) reminders when your account is running low on funds (and of course it will let you know if you run completely out). The reminder levels come pre-configured at $5.00 and $1.00, but you can add, change, or remove them at will.
This allows you to limit your exposure. If for some reason your website spins out of control, you won't open your mailbox and find a $1,000 bill. It'll burn through whatever you have on deposit and then shut down, allowing all of us to work together to find and fix the problem before it gets out of hand. Your liability can never exceed the amount of money you have on deposit.
Holding a deposit also helps us limit our exposure. By holding the funds for a site in advance, we ensure that nobody ever incurs charges for services they can't pay. If we didn't do that, your costs would go up because our members would ultimately have to pay to cover the costs of all the other people who defaulted.
Maintaining accounts lowers our overhead. We don't have to send out bills, past due notices, or go to collections. That's one more unnecessary thing you don't have to pay for, meaning your costs stay low.
It means there is no list of credit card numbers or bank accounts waiting around for hackers to find.
We say: go visit somebody else's website. Look for their affiliate program. Find out if your web designer is getting a kickback for referring you. Some providers pay 10% or more every month.
Affiliate programs make it difficult for a web designer to make objective recommendations about what's good for your business. So good web designers generally don't participate in affiliate
programs, and you can rely on their advice. We don't have an affiliate program, so when someone recommends us, you can be comfortable that it's because they like us and think we're a good fit for you.
On the other hand, good designers like to use the tools they know will give good results. Maybe your designer has had good luck with somebody else in the past. Maybe somebody else has a system that your designer is already very familiar with. In a case like that, sometimes it's better to go with somebody else. We'll be here if you need us.
Our pricing plan is designed to be fair to you and fair for us. It represents our actual cost to provide the service. In the case of resources, for instance, this is literally true: all revenue from resource charges is channeled directly into the acquisition and maintenance of hosting hardware. And by "hardware" we don't mean a Hummer with a sexy custom "NearlyFreeSpeech" wrap on it.
Our pricing plan is simple and straightforward as well as very competitive. You pay for what you use, and you don't pay for what you don't use. That's all there is to it.
Prices that appear better than ours fall into two categories: big bundles and temporary loss leaders. Our thoughts on big bundles are detailed elsewhere. As for loss leaders, as long as the hosting business exists, there will be somebody offering free or below-cost service because they think adding customers is more important than building a sustainable service. Competing on price with every free-today-gone-tomorrow hosting provider that comes along would simply guarantee that we'd lose what really makes our service the best deal: its simplicity, honesty, and sustainability.
It's not easy. For one thing, we keep overhead to a minimum. No fancy multi-acre Silicon Valley office palaces with slides and wandering masseurs here. No business development teams. No commission-driven sales force.
Also, we try to avoid doing stupid things that make no sense just because we heard someone else made a lot of money that way. That really helps.
This is not a loss leader, a limited time offer, or restricted to only certain people. This is our business model, and it works.
There's no other way to put it: we're complete control freaks. Our policy is simple: if we don't have a remote-controlled explosive collar welded in place around your neck, we don't give you root on our network. Since there are currently no commercially-available remote-controlled explosive collars licensed for public use, we don't give you root on our network.
This is very good from a security and reliability standpoint, but it does rule out offering these sorts of services.
However, our hosting services have gotten more and more powerful over the years, to the point where you can do pretty much anything on our service that you can do with a VPS, dedicated server, or colo, as long as it's web-based. If you're under the impression you need a VPS or dedicated server to run your web site, try asking about it in our forums, because there might be a better way.
The notable exceptions to this are due to legal restrictions rather than technical ones. For example, handling credit card numbers directly on your site. (We recommend using a third-party service run by security experts instead. That's what we do.) Similarly, if you are handling regulated health information, there really is no alternative to a provider that can offer HIPAA-compliant hosted services (and, regrettably, the massive associated expense).
Typically, not much. Our system includes dynamic load-balancing and scalability so it can adapt quickly to dramatic changes in your traffic levels. (It is possible to create a site that's so inefficient that it can't keep up no matter what we do, but that's pretty rare.)
A major "slashdotting" (or insert the surge site of the week here) of a site hosted on our service will cost you (on average) less than $10, one time. There's no higher-tier pricing to get permanently pushed into, and we won't cancel you for having something to say that people actually want to hear.
This happens to one of our members about once a week, so you can bet we know how to handle it. Or rather, our systems do. Our load-adaptive clustering technology is at its best when handling demand surges, and our pricing is at its best when you'd prefer not to be billed based on a 1% event the other 99% of the time.
Note: Our service is based on science, not magic. It will not make slow sites run quickly, nor will it make sites scale if they aren't built for it. Your site must be able to complete requests at the same rate they come in. If it cannot, for whatever reason, then there is nothing our system (or any other) can do; you're gonna have a bad time. Please take this into account when designing sites intended for high traffic levels.
When you create your website on our service, you will be asked to give it a "short name," which is a brief one-word name for your site that must be unique across our entire service, and we give you a built-in hostname based on that.
For example, if you choose example as your site's short name, you will always be able to access it as http://example.nfshost.com/.
If you don't want DNS or a domain of your own, you're welcome to use this name for your site at no additional cost. If you do use a domain of your own, then having your site available under this alternate name may help you troubleshoot any problems during the setup process, as well as provide a backup if there is ever a problem with your domain.
Because the servers we buy and the bandwidth we obtain are very competitively priced, but they still do cost money, as do the skilled professionals that run them.
We get this question from two different angles. First, there are always people who just want something for nothing. We don't have much to offer those people.
The second angle comes from people who would like to see us offer some sort of ad-sponsored free service. There are two primary reasons we have not pursued that:
If it were possible for us to sell ad space on your site and make money from your hard work, wouldn't that be us ripping you off? You are welcome to sell ad space on your site, if you wish, and you are the only person who should profit from that. If you want to try this out, Google AdSense works with our service. Knock yourself out.
Accepting sponsorship for a site places additional constraints on the content of that site. If we did this on any kind of scale and were dependent on that revenue, the sponsors would gain enough influence over us to potentially force us to censor our members. That's unacceptable.
Finally, we would encourage you to remember the time-tested truth about free services on the Internet: if you're not paying then you're not the customer, and if you're not the customer then you're the product. And if that doesn't put you in mind of the mental image of a herd of cows milling around outside a slaughterhouse, well, we admire your optimism.
Our customers are not advertisers, not venture capitalists, not the government, and not public opinion. Our only customers are our members.
Of the two, storage is easier to understand. Just like you, we have hard drives (except larger and probably more expensive) and we store the files that make up your site on them. Storage refers to how much space those files take up. Storage billing is measured in units called megabyte-months, which refers to one megabyte stored on our system for one month.
Bandwidth, on the other hand, refers to the amount of data that is sent out when people visit your site. Bandwidth is measured in units of gigabytes. If your page (including any graphics and such that may go with it) takes up one megabyte of space, then about a thousand people (1024 actually) would have to download the whole thing to get to a gigabyte of bandwidth, and that's what you'd be billed for.
It's simple. We don't want to confuse people into thinking we're anything like other hosting providers. Our simple, text-based layout is designed to load fast, to be easy to use, and not to try to distract you from making an informed decision about us. As if that's not enough, we also think Jakob Nielsen is pretty cool.
So, sure, we could follow the crowd and get stock graphics of impressive racks of equipment and inspired-looking people staring blankly into space. We've even been told we can't possibly be taken seriously as a hosting company unless we have them. But we're not buying. Those other companies can keep the sort of people who make hosting decisions based on how cute the model on the home page is. Our members are way too smart for that, and that's just how we like it.
And psst, we'll let you in on a little secret. Not all of our servers are the same color. Scandalous, we know.
No, our domain registrations services are provided on a cost-recovery basis as a service to our hosting members, and are not intended to be used as a standalone product. We are not, nor do we have any interest in being, a general-purpose domain registration provider.
Consequently, while we do not impose any restrictions on the use of our domain registration and RespectMyPrivacy.COM services, our system is specially designed to facilitate use of registered domains with our hosting services. If you wish to use these services for other purposes, you are welcome to do so, with the following caveats:
it may require additional effort on your part to set up,
our prepaid balance model is not optimized for domain-only usage, and
we will not be able to provide technical support for usage of domains in conjunction with third-party services.
This is a tough question. We do host websites that get attacked by a wide variety of different methods. However, the variety is so wide that there is no "typical" attack scenario or "average" outcome that we can offer as an example.
At any given time, our network is typically experiencing between zero and three denial-of-service (DOS) or distributed-denial-of-service (DDOS) attacks. Most are short, lasting only a few minutes or hours, but the longest lasted for over a month. Most are not service-disrupting, but occasionally they can render a member site inaccessible, and rarely, if they are significant enough, large-scale DDOS attacks can sometimes briefly disrupt our entire service. (This is equally true of all web hosts.)
To help protect our members' sites, we employ a large number of passive network features like connection filtering and firewalls. These are generally very effective against the everyday attacks we most frequently experience. When attacks go beyond the simple, an active response by NearlyFreeSpeech.NET personnel is typically required. Our active response to attacks on member sites (or on our service itself) is roughly proportional to the square of the disruption caused; our response escalates very quickly as attacks become more severe. Thanks to our long experience in the area, we have a wide arsenal of tools that can be dynamically employed or tuned to help mitigate serious attacks. We take keeping our members' sites online very seriously!
Having your site attacked does sometimes consume resources, e.g. bandwidth, that we charge for. The cost of such an attack depends on the type, scale, and duration of the attack, as well as in large part on your actions before and during the attack. Since these factors are not under our control, vary widely, and cannot be accurately predicted, we will not under any circumstances attempt to estimate what the financial implications of a hypothetical attack might be. If you want such an estimate, simply figure out the bandwidth that would be used based on the size of your site and the anticipated volume of requests.
However, since our service is paid in advance, you always have complete control over your maximum financial liability simply by controlling the balance of your account. If you feel your site is attack-prone and you are primarily concerned about costs, we encourage you to maintain a low account balance to limit your exposure. Then, if a situation arises, you will be able to make an informed decision about your best course of action before incurring any significant expenses. If you feel your site is attack-prone and you are primarily concerned about availability, we suggest that you maintain a larger account balance and customize our account balance warning feature to notify you if your expenses spike in an abnormal way.
Our service is based on personal responsibility. Although our TACOS ensure that you have broad discretion in choosing what to say on your site, if you choose to say something controversial then you must be prepared to be first in line to bear the consequences. We will not indemnify you or waive any costs you incur arising from an attack on a site you host; we are a hosting provider, not an insurance provider.
In all cases, if you are concerned about your site being attacked, you are your own first and best line of defense. You should design a site that is lightweight and fast-loading so that it remains available under heavy load and minimizes bandwidth cost.
If you run into a problem with someone attacking your site or trying to bleed your funds dry, please feel free to contact us. It is absolutely not our intention to sit back and laugh while someone drains your account, whether your site content provoked the attack or not. In some cases, we can block obvious troublemakers and certain types of attacks so they will not reach your site. But since you are the site operator, we will expect you to take all reasonable measures to protect yourself first. Example 1: If someone is posting rude comments on your forum site, you will need to use your forum's blocking features to handle it. Example 2: If someone writes a script to repeatedly download the largest static banner graphic on your site, we may be able to block their IP address for you.
With all that said, it's worth noting that most sites will never be attacked directly and have absolutely nothing to worry about in this area. Even given our libertarian TACOS, fewer than 0.1% of our hosted sites have ever been targeted by noteworthy attacks.
Not at all! It's true that our libertarian attitude toward personal responsibility attracts a handful of controversial websites, some of which make a person wonder, "Ok, sure, you can say that, but why?" However, the vast majority of sites we host (greater than 99.9%) are perfectly ordinary blogs, forums, wikis, and personal pages run by people just like you.
For the bulk of our member base, the "fringe" web sites we host frequently serve as the proverbial canary in the coal mine: they act as our global censorship early warning system. As long as the fringe sites can remain online, we can all be confident that the rest of us with more moderate views have real freedom to express ourselves. When people (or governments) attack such sites or attempt to get them shut down, we learn more about what legal and technological techniques we need to use to keep your site protected.
NearlyFreeSpeech.NET isn't necessarily about saying something controversial. In a lot of cases, it's merely about knowing that if you need to someday, you won't find out that your freedom to do so atrophied away while you weren't looking.
NearlyFreeSpeech.NET provides our members a very specific service: it is designed for people who want to tinker with their website at a very low level and squeeze every last drop out of it. We are in some respects similar to an auto parts store, rather than a mechanic. NearlyFreeSpeech.NET will sell you an alternator for your '72 Impala*, but both the responsibility to determine that the '72 Impala needs an alternator, and the job of installing it remain with the customer. All the knobs, tweaks, options, and flexibility we provide can become a real frustration for a person who just wants to be done already.
Furthermore, as a small business ourselves, we understand that one of the keys to success is for the principals to spend as much time as possible focusing on the high-skill areas and as little time as possible on "have to" stuff, including accounting, legal issues, and maintaining web pages. Every minute that we spend on something that we're barely competent or outright bad at is a minute we're not spending leaving the competition in the dust. Thus, we try to outsource as many of those tasks as possible so we can focus on doing what we're actually good at.
For that reason, in general, we find it difficult to recommend our service to new and small businesses; the do-it-yourself nature of our service and the limited support that entails can be anathema to someone who really needs to be spending their time somewhere else. So it's often better to pay (a lot) more and get a turnkey solution. But there are two exceptions to this:
First, for a lot of businesses these days, the website is the business. If you're a high-tech person trying to build a small business around a dynamic web site and you need advanced control over the programming and site configuration, as well as excellent speed and scalability at minimal cost, NearlyFreeSpeech.NET may well be perfect for you.
Second, the economic realities of new businesses often dictate that the owners have to do some of the things that are outside of their core skills. If money is tighter than time and the alternative is not to have a site, the ability to create a site at NearlyFreeSpeech.NET for pennies may be priceless, even if it takes a little more work.**
*As long as your '72 Impala supports HTTP and is hosted on our service.
**But don't expect to see any "NearlyFreeSpeech.NET: It's better than nothing!" marketing campaigns.
We don't have the resources to review content. We can't provide legal advice. And we don't offer a service that is intended to (or, by any stretch of the imagination, could) protect our members from everything they might bring upon themselves by what they choose to do.
If you are concerned that you might encounter problems with the content you want to publish or how you want to use our service, we'd strongly advise that you consult an attorney familiar with such issues.
Free speech is not just a right; it's also a responsibility. Each member must be willing to accept the consequences of their actions and should not expect us to do so for them.
For your reference, here are links to the relevant fine print:
This is a question only you can answer. Sites are billed based on the resources they consume (bandwidth, storage, and CPU/RAM). The cost is therefore based on the size and popularity of your site, as well as any optional features of our service that it uses (like domain registration or MySQL).
We don't know any of those things about your site, and we are not able to estimate things about your site that you don't know yourself. If you have your own estimates or past records about your site's size and popularity, you can use those, plus the pricing information available on our site, to estimate the approximate cost.
We do provide a Pricing Estimator you can use to try to get an idea of how much your hosting may cost.
It depends. (Of course.) The short answer is: Not only don't we know, we can't know. The long answer uses the word "however" a lot.
Shared hosting has a well-earned reputation for volatility. You're sharing resources with other people. Who knows what they or the visitors to their sites are about to do? However, the most common causes of downtime are specific to the affected site. An expired domain, runaway scripts, or running out of funds are much more likely to cause downtime than a service failure.
We find that when people ask about uptime, they expect a magic number with a certain quantity of nines in it. That number allegedly represents the fraction of the time our service is available. However, the availability of "the service" depends on the definition of "the service." We host a large number of sites and they don't all move in lock-step. One person's downtime might not affect anyone else.
It would be easy (and blatantly dishonest) to pick an arbitrary definition that would allow us to claim 100% uptime, or any number of nines we want. Likewise, with enough hardware, something is always offline for maintenance. So we could make an argument for 0% uptime. (Though we prefer not to.) In the rare case where a production server crashes, it usually affects a small percentage of our members' sites for a few minutes. Sites move back and forth, servers go up and down, and most of it happens without any visible effect.
There's also the philosophical angle. If a server reboots in the forest, but no one tries to access it, was it really down?
At many providers, your site is 100% dependent on the availability of a single physical server. If it fails, you're out of luck. Our clustered approach provides resiliency against many types of hardware problems. However, we do develop and maintain our own clustering software. Occasionally something incredibly weird may happen here that would (or could) never happen anywhere else. Such events are rare, but not without precedent.
Sites hosted at NearlyFreeSpeech.NET run a small risk of being "collateral damage" of a denial-of-service attack not aimed at them. But the flip side is that we have extensive experience with such attacks. We're able to mitigate most small and moderate attacks without disruption. So although the risk might be higher, the expected impact is lower. There is (most likely) not much practical difference in DDOS risk between competent hosting providers.
All in all, our overall service availability is probably above average to very good when compared to other shared hosting providers. However, "overall service availability" is meaningless if your stuff is down. We understand that. One site offline because of a service malfunction is one too many. That's why we monitor our systems and services continuously from multiple offsite locations and respond to problems as quickly as possible, 24x365.
We have been using "cloud-like" principles since we started in 2002. We make heavy use of multiple virtualization technologies, hardware independence, shared resource pooling, load balancing and clustered job distribution. But we do not consider ourselves to be a cloud computing provider, if only because that's such a marketing term and really means very little. (We've seen it argued that "the cloud" is anything you don't host on equipment you own and operate yourself.)
From a geographic and legal standpoint, our entire business operates from inside the United States of America. Almost all of our services are provided from our primary datacenter in the New York City metro area.
From an Internet standpoint, we are well-connected to multiple Tier 1 backbone providers. We do not use bandwidth from the "discount" carriers frequently associated with inexpensive web hosting providers.
Keep in mind that although our company is solely under the jurisdiction of United States law, our Terms & Conditions of Service do require you to follow the laws of whatever country you are in. (With certain limited free-speech-related exceptions available only with our prior written consent.)
Also, although much has been written lately about how imperfect the US government is when it comes to Internet issues, it remains the best choice for hosting. Most of the top countries one would consider as alternatives have already been caught doing the exact same stuff; at this point it's safer to assume that the rest just haven't been caught yet. But in the end, there aren't any other countries that have good Internet connectivity and infrastructure, fundamentally recognize the individual right to freedom of speech, and have a legal system that doesn't force web hosts to remove anything that generates complaints.
The US isn't the perfect choice, it's just the best one. So we'll keep working to make it better through our support of the EFF, the Freedom of the Press Foundation, and similar organizations.
The exception to this is that if your web site will greatly antagonize the US government or is illegal in the US, you should not use any US-based host, including us, to host it. That's just common sense.
No. We provide support primarily through the ticket-based issue reporting system on our site and through our forums.
Providing good-quality telephone technical support is very difficult and expensive. Since most of our members don't use support and, more importantly, don't want to pay for support they don't use, maintaining a telephone support option for the few people who would use it is not economically feasible. We also have a moral objection to call centers; anyone who has ever seen, run, or interacted with one knows that that's no way to treat human beings, regardless of which side of the phone they're on.
Most companies as small as ours that offer telephone support do so by outsourcing it. We looked into that, and it's a very cost-effective approach, but the result is moderately awful; it still involves call centers, and it fills them with people that have little to no knowledge about the specific system they're "supporting." When a call comes in, their screen flashes up with the name of the company they're supposed to represent, and since they know little to nothing specific about the company or how its systems work, pretty much all they can do is search the FAQ and read entries to callers in the hopes that they find the right one. While that works in a lot of cases, it wouldn't work here. Soul destruction aside, our members are smart, motivated and tend to have a lot of experience; if their questions are in the FAQ, they typically prefer to find and read what they need for themselves.
However, there are web-hosting companies that do a great job with telephone support, especially for new customers and people inexperienced with web-hosting. If that's something you're looking for, you may find that one of those companies is a much better fit for your needs than we are. And although they may be considerably more expensive, the extra investment is often well worth it if that type of extensive assistance is something you expect to use frequently.
First and foremost, do not let the other person give you their login credentials. If they do, don't use them. Doing that will result in a suspended membership. That will cause both of you all kinds of problems and misery without helping anybody.
That means that to help someone else with our service, you're going to need a (free) membership of your own. There are two fundamental reasons for this:
When you go to the signup page, you'll see bold print warnings that memberships are created for individuals (not companies or organizations) and that they may not be created for others, transferred, or shared. Make sure you heed those warnings. If you don't: suspended → problems and misery → nobody helped.
Creating your own membership will allow you to look around our system and make sure that you're familiar with the features and limitations of our service and that you're comfortable that you can provide the necessary help.
Second, it matters what type of help they need from you.
If the person only needs help managing a website's content, we have a feature called adjunct access that allows one member to edit another member's site. There's no fee for that; you can create a membership and be given adjunct access to another person's site without ever paying anything. Full information about adjunct access is available in the version of our FAQ on our member site.
We also offer the ability to share an account between multiple members. Account sharing is the best way to organize complex projects or hosting for organizations where more than one person must be involved. Account sharing doesn't require anyone but the "main" member to pay anything. Full information about this is also available in the version of our FAQ on our member site.
If the person needs more help than that, there are two basic ways to proceed.
If you want to take over completely, you and the other person can each log in to your own memberships and submit free requests to transfer their stuff to you. The process for this is also described in our member FAQ. For simplicity's sake, what the other person will ask to have transferred, and what you will ask to receive, is "everything."
If the above is not possible or not desirable, or if you need more help from us for some special situation, the other person will have to contact us through our site and give us explicit permission to discuss all the details of their membership with you. Once that's done, you can contact us the same way to have that discussion. Then, and only then, we can work with you to figure out the best way forward. Note that both parties will need subscription memberships (our higher, more expensive tier of membership which includes individual private support) to do this.
It's important to emphasize that due to our privacy policy, we will not under any circumstances discuss the details of any person's membership with any other person in the absence of their express written consent provided through our site.
There are certain specific cases where a VPS is a better fit than our service:
If the public face of your application is not web-based, it won't work on our service.
We provide a very full, carefully-engineered environment that is suitable for a wide variety of applications and customizable for lots more. But if you need the ability to manipulate the environment at a very low level, such as loading custom kernel modules or filesystems, you won't be able to do that here.
If you want to learn about a career in the fast-paced, exciting world of Internet system and security administration, our service isn't a good place for that.
Likewise, there are several cases where we are a much better choice than a VPS, but they all boil down to this: you have stuff to do, and spending lots of time installing, customizing, tuning, and maintaining a VPS isn't it.
Whether that's running a production application, developing your big idea, or just learning how to program, there's a good chance you're a lot better off here than you are at a lot of other places. We call ourselves a "do-it-yourself" provider, true, but we try pretty hard to provide you a great environment and a set of high-quality tools to do your "it."
(And before you make a decision between our service and a VPS based on price, please question your assumptions.)
This is a source of much confusion to people new to setting up websites and many experienced webmasters. Each of these services has a different purpose and different costs.
Together, these three components form the chain that links a domain name (like example.com) to a web site (like example.nfshost.com).
Domain Registration is the process of reserving a domain name with a central authority (called a registry) so that no one but you can use it. Domain names are of the form example.com as opposed to hostnames (aka site aliases), which tend to be of the form www.example.com. (You can use example.com as both a domain name and a site alias, but doing so has certain hard-to-understand limitations, and we do not recommend it.) Domain registrars act as intermediaries between you and the registry, and they charge a fixed annual fee for this service. We provide domain registration services for the most common generic top-level domains (aka "gTLDs").
DNS or Domain Name Service is used to tell the world what you want to do with your domain name. Most commonly, it is used to create a hostname. Most hostnames have another word attached to the domain name like www.example.com. Each hostname corresponds to a website. It is possible to have more than one hostname per website, but a hostname can only refer to a single site. DNS links this hostname to your website, so when people want to visit www.example.com, their web browser can find it. It's a little like calling directory assistance to find a phone number based on someone's name. We offer a low-cost DNS service that provides this functionality.
A web site refers to the storage and retrieval of your actual web pages. After a web browser has checked with the registrar to see that your domain name is valid, and you have checked with DNS to find out what web host has your website, it goes to that host to retrieve your web site's pages. If you don't have a domain registration or DNS service, you can still access a site hosted here using its short name in the domain nfshost.com, like example.nfshost.com.
For more information about domain registration and domain name service (DNS), please see those sections of our FAQ.
If your domain is registered and has DNS service, but your domain name does not point to your site, the most likely cause is that your site is missing an alias.
An "alias" tells our systems what name(s) are associated with a web site. An alias will commonly include "www." (e.g. www.example.com) or be just a domain name (e.g. example.com). In most cases, you'll want both.
In the "Short Name" column, click on the name of the site you just created.
If you don't see the alias you want to use already listed under "Site Names & Aliases," click the "Add a New Alias" button at the bottom of that same box.
Follow the instructions.
While changes often take only minutes to take effect, they depend on the propagation of DNS updates, which can sometimes take an hour or more.
See also the complete "Domain Name Service (DNS)" and "Domain Registration" sections of our FAQ for other related issues that could keep your domain from pointing to your site.
DNS considerations: Please be aware that if you are using our DNS service, adding an alias will result in the automatic addition of a CNAME record to your domain's DNS. If you later want to point the same hostname (www.example.com) elsewhere via a new DNS record, delete the alias you created here first so that the CNAME record our system added to your DNS will also be removed; otherwise, you won't be able to add a new DNS record for that hostname.
If you already have a correct alias added to your site and you have set up our DNS, but it is not working, it is also possible that you have incorrect name servers listed on your registration. See this FAQ entry for more information.
To get the most out of WordPress on our system, especially to make it run well under heavy loads, please take a look at our Advanced WordPress Configuration guide.
Yes. Assume that we are storing crates of sweaty dynamite on top of the servers that hold your important data and design your backup strategy accordingly.
That sounds absurd. And it is; we take your data very seriously. But a good backup strategy assumes the worst, so this is pretty much the only time we'll tell you to assume we're incompetent. If you don't, whatever backups you do—or don't—make are unlikely to help in a situation where we can't.
For sites, synchronization tools like rsync or Unison or version control tools like git can help back up your content. If you're developing your own site, we recommend building it locally and using a tool like one of these to send it to us. That ensures that you've always got the master copy.
MySQL backups are also strongly recommended, especially before undertaking major changes to your MySQL data.
If it's already too late and you haven't made or can't use your own backups, we may be able to help. But as much as we love to save the day, there are no guarantees. It stinks when we have to tell someone that we can't help them get their hard work back. Please make your own backups!
In the Actions box in the upper right, choose the "Create a New Site" action.
Choose a funding source (if you have more than one account).
Pick a "short name" for your site.
Select the "Next" button.
If you have another name (or names) for your site (like www.example.com and/or example.com:
Enter the only or most important name for the site (usually www.example.com) as the Canonical Name.
Enter any other names as an "Additional Alias." (If you have more than four, you can add the rest later.)
Indicate whether you want us to set up DNS for any domains associated with that name. Unless you know you're getting DNS from a third party, you probably want "Yes."
If not:
You don't need to do anything on the aliases page.
You'll be able to access your site using its short name plus the domain nfshost.com. For example, if your site name is example, then you have the option to access it as example.nfshost.com.
The remaining settings are optional; the defaults will work for almost everyone. The choice of a Production or Non-Production site may be worth reviewing, as it affects the cost of your site and what you're allowed to use it for.
Select "Finish" (or keep hitting "Next") to get to the summary of site setup.
Make sure everything looks good to you.
Select the "Create This Site" button to make it happen.
It usually takes new sites less than a minute to get set up. Once it's ready, you can get started uploading your content.
This is caused by browser caching and/or the mechanism we use to distribute your content within our network efficiently. If you wait a few minutes, the files should resynchronize automatically.
If you prefer not to wait, you can also help the process by visiting the modified page yourself and doing a forced reload. For Internet Explorer and Chrome (Windows), this is done with CTRL-Refresh (or CTRL-F5). With Firefox, Safari, and Chrome (macOS), this is Shift-Reload (Ctrl-Shift-R on Windows, Command-Shift-R on Mac). This will force that page and all related content (e.g., images, scripts, and CSS) to be resynchronized immediately. Since we have a lot of caches and requests are load-balanced among them, you may need to do this a few times to get every cache that might answer for your site.
If you wish to do this from the command line, you can use curl to force the refresh:
Again, do this several times for each affected URL to make sure you get all the caches.
There is a case where if you access the site before the IP addresses are assigned (within the first minute after it's created), you'll get a DNS error. Once that happens, some Internet Explorer versions will keep returning errors long after the site is created, even if you use a forced refresh. Waiting a few minutes, restarting IE, and sometimes rebooting have all appeared to help this under various circumstances.
If you have uploaded content, but your site still displays the new-site "Not Available" message, you should be able to use this same technique to get rid of it.
No. Domain registration is an entirely separate and required step if you want to use a domain name (like www.example.com) with your web site. Please see this FAQ entry for further explanation of domain registration, DNS, hosting and related terms; please see this page for information about our domain registration service.
You might also wish to read our Getting Started Guide for a step-by-step approach to registering a domain and setting it up with your web site.
Many of the changes you make have immediate effect. The ones that don't tend to involve DNS or domain registration changes.
Most DNS changes, such as associating a name like www.example.com with a site hosted here (by adding an alias), take effect within a minute or two. However, there is a catch. If you recently accessed the name before you set it up, your browser and/or local ISP may "remember" the old information. (Either that it pointed somewhere else or that it didn't work.) If you're moving things around on our system, it should be visible within a couple of hours. If you moved a domain over from somewhere else, it might take longer depending on their setup.
The time it takes to see DNS changes is controlled by the time-to-live (TTL) value for the relevant DNS records. (If a record doesn't exist, the domain contains a setting called Minimum TTL, which will be used to tell people how long they should assume that record will continue not to exist.) When you look up a domain name, your local name server (usually run by your ISP) will look at the TTL value and "remember" (cache) the answer for long, even if there are changes in the meantime.
The root DNS servers operated by the domain registries store your name server records with TTLs of two days. That means if you change your domain's name servers, that change can take up to two days to be fully visible throughout the Internet. (The same applies if your domain expires and gets the expired "parking" name servers, so don't let that happen!)
For a newly-created domain name, things will often work within a few minutes if you don't try to see if it's working until it's already working. If you happen to hit it before it's ready, you'll trip the DNS TTL delay and may have to wait a bit longer. If it's not working after an hour or so, check for configuration issues with your site, DNS records, or nameserver settings.
You should always be able to see a new site using our nfshost.com domain within a few minutes.
In addition to our member FAQ, you can find relevant information in the following places:
Our home page includes links to lists of details (including version information) for the PHP, MySQL and CGI software running on our servers.
Our member Discussion Forum is a great place to search for information about what you want to use. Frequently, other members will have tried it and discussed doing so on our forum. You can also ask questions to find out other members' experiences. (Note that you'll need to sign up on the forum to have a user ID associated with it; your member user ID will not be used.)
Our Member Wiki is another growing resource of information about how to get things working.
See the Support section of the member site for more support-related links and information.
Yes it does. We use Unix systems, which employ a case-sensitive filesystem. It is entirely possible to have one file called index.html, another called Index.html, and another called INDEX.HTML. Of these, only index.html will be recognized and examined by the system.
This occasionally comes as quite a shock, particularly to Windows users who are used to ignoring filename case.
To avoid confusion and promote consistency, it is recommended that all files be uploaded using only all-lowercase filenames unless there is a specific reason to do otherwise. By adhering to this convention, you never have to wonder or remember whether (or how) you used uppercase letters in your filenames.
Many uploading utilities on systems that ignore case distinctions offer the ability to automatically convert filenames to lowercase. Using this option is highly recommended, but it is also necessary to make sure references to external files, such as images linked in an HTML file, also use the correct case.
These instructions are for domains that are not currently registered with us:
First remove any subdomains. (Subdomains are rarely used, and even more rarely necessary, but if you have any, you'll have to remove them first.)
Remove any site aliases that exist within this domain: Visit the Sites panel and click on the site name; the next page will list the aliases and provide "Remove" buttons.
Remove any DNS or email services on the domain. Visit the Domains panel and click "Manage" under the "DNS" and/or "Email" columns; select "Permanently Remove DNS" and/or "Permanently Remove Email Forwarding" from the "Actions" box on the next page, respectively.
Go back to the Domains panel and a "Remove" link should become available in the "X" column.
If the Remove link is not there, then the domain is either registered with us or is otherwise in use with some other service.
On the Sites tab, select the site's short name from the first column of the list to access the Site Information panel.
On the Site Information panel for the site, in the upper right corner, inside the Actions box, select the "Remove This Site" action.
On the "Remove Site" panel, enter the short name of the site and your member password.
(Note that instinct may make you type your username here; that's not correct. The form asks for the site name to minimize the chance of deleting the wrong site if you have more than one.)
Select the "Remove This Site" button.
It takes our system a couple of minutes to fully remove a site.
There are four kinds of log files available at NearlyFreeSpeech.NET:
Access log
Error log
Rewrite log
Daemon log
These logs (if enabled) found in the /home/logs directory of your site.
Access log (/home/logs/access_log)
Each line in the access log represents one access to your website. It contains information, like what IP address accessed your site, what path they accessed, what web browser they used, etc. Analytics programs like AWStats use this type of log file. The access log can take up a lot of space, so it is disabled by default to save you money.
Error log (/home/logs/error_log)
This contains information about problems with your site. Although it records generic problems, like records of attempts to access pages that don't exist, it is most important to web developers and people with complex software loaded on their site. Whenever software running on a site has a problem, it should (but doesn't always) write something about it in the error log. Finding that message can save you fruitless hours of wondering what the heck is wrong with your site. For sites created after 2021-01-30, the error log is enabled by default.
Rewrite log (/home/logs/rewrite_log)
Rewrite logs track internal changes made to URLs by Apache. They're generally only useful if you've set up your own rewriting rules, and they aren't working as you expect. Rewrite logs are disabled by default. Enabling the rewrite log can tank the performance of your site. Enable it only if you are having rewrite-related problems, and turn it off as soon as you fix them.
Daemon log (/home/logs/daemon_example.log)
If you are running a server type that allows daemon processes, each daemon process gets its own log file (replacing example with the daemon's tag), that receives its standard output and error.
As long as the system is writing to a log file, you cannot modify or erase it. Once you rotate the log file and the system starts on a new one, you can delete the old one if you wish. You can read your log files even if they have not been rotated, you just can't delete them while a server is still using them.
You can access and delete your old log files via ssh or SFTP by looking in the /home/logs directory. (But you'll still have to rotate them before you can do anything but look.)
If you've disabled logging, the option to rotate them will not be available to you. Enable your logs, rotate them, disable them, and then delete them.
If you have log files enabled, you can ask our system to rotate them from the Site Information page for your site in our member interface.
When you ask to rotate your logs, our system waits for an opportune moment and then does it. Your access_log file, for instance, becomes access_log.old, and a new access_log is created. It may not be right away, but it usually takes just a few minutes. If there was already an access_log.old, that file gets a name based on the timestamp of the log file, such as access_log.20160828.
Before August 2016, non-transparent compression options were available. Now, the filesystem already incorporates transparent LZ4 compression, which does a great job on log files while keeping them easy to access and analyze. If you previously had compression enabled, it will continue to work, but you can deactivate it on the Site Information panel.
Choose the site's "Short Name" to load the Site Information page.
Choose "Enabled" for the access or error logs (or both).
Choose "Save Changes."
Wait a few minutes for the change to take effect.
If you're planning to measure any kind of statistics, enable the access log. For best results, enable it a week or so before measuring your statistics, as data from a longer period of time will produce more informative reports.
To find and debug problems with your site, enable the error log. If you ask for help with an error message received from your site, we will often ask what your error log says about it. If you do not have your error log enabled, we may not be able to help you diagnose some problems.
We also provide a rewrite log which can be enabled in the same way, but may be set to varying levels of verbosity. Do not enable the rewrite log unless you are having problems with RewriteRule directives in your .htaccess file, and disable it as soon as you fix them. Using the rewrite log will dramatically slow down your site.
304 is the HTTP status response for "not modified." It is used in our log files to indicate that the logged request was actually served by some other part of our network. Usually only simple files, like static graphics and files, are eligible for this type of handling. Dynamic content, such as PHP and CGI scripts, will typically be served (and logged) in its entirety unless your application generates appropriate cache-eligible headers and 304 responses.
This code can also appear for other reasons, such as if someone accesses your site through a web cache.
This is largely due to requests filled by other parts of the network, which may appear in your access log as 304 responses with a size of 0 bytes, or if served entirely from memory, may not appear in the access log at all.
The number you see for bytes with 200 response codes should match the size of the named file unless it is a PHP or CGI script. However, every object served regardless of origin has some overhead (HTTP headers) that is also not reflected in the access log.
Our log files are based on the Apache-standard "combined" log file format, which is a superset of the "common" format. This format is good for web log analyzing software. The fields, in order, are:
The IP address of the machine that requested the page. If you get a "-" in this field, it may mean that your site performs HTTP accesses on itself, or that we had to test your site with some internal application.
dash
This field used to be used, but isn't anymore. Lots of log analyzers still expect it to be there, so it always appears as a dash (-).
username
If you use Basic HTTP Authentication, the authenticated username will appear here. If you don't, it will be a dash (-).
time
The time in the format DD/Mon/Year:HH:MM:SS tzone
request
The request method, requested URI, and protocol, like GET /index.html HTTP/1.0.
status
The return code. The most common codes are 200 (ok), 304 (served elsewhere), 404 (file not found), and 500 (internal server error - a script error or a problem with our server).
bytes
The number of raw bytes of content served. This number does not include HTTP headers, transfer encoding, or TCP/IP protocol overhead.
referer
The page that contained the link to the requested resource. You can use this to see who is linking to you, and weblog analyzers use it to map your site. "referer" is not a typo, although it is spelled incorrectly. It's actually in the published standard that way.
useragent
The web browser sends this to identify itself. Lots of log analyzers can graph this.
More information about Apache log file formats is available on the Apache site.
The .old log files are never automatically compressed. If you rotate again, it will be renamed based on its last-modified date and only then will it be automatically compressed.
This is for two reasons. First, log entries come from many different parts of our network so there needs to be a "cooling off" period after rotating to make sure all parts of the network have switched to the new log. Otherwise, stuff might still be logged while compression is happening, and it would get lost.
Also, many people like to run analysis against a static log file. That way, if you change an analyzer setting and run it again, or if you want to do more than one thing to the log, you're working with a consistent set of logs. After log files are compressed, they're a lot harder to analyze, so keeping the .old file around often makes log analyzing much easier.
You're free to remove the .old log file yourself if you like, although we recommend waiting until you see log entries appearing in the new log file. If you rename or compress it yourself, it will not be auto-rotated in the future.
The error log is a "stream of consciousness" output of all the various programs you run on your site. As such, it does not have a specific format, other than that the most recent errors are at the bottom.
Nothing extraordinary. The change will only apply to newly compressed log files. Your old ones will be left as-is. If you want to update them to your newly chosen format, it is possible to do this from the ssh command line.
If you know what your contact email address is, but you've lost access to it, usually that is no problem. As long as you still know your login and password, you can just log in, go to the profile tab, and change the email address we have on file to your correct address.
The only time this becomes a problem is when you have lost access to your email address and you can't log in. That's a much more difficult situation. If you contact us from an email address not associated with your membership, we have no way of differentiating you from someone who set up that email address five minutes ago in your name to steal access to your membership. That's one reason why it's very important to keep your member contact email address up to date at all times. (But if you're reading this, it's probably too late for that reminder to be helpful right now, so just keep it in mind for the future.)
To resolve this situation, you will have to have us change the email address associated with the membership. However, that can only be done after completing our login recovery process. To complete this process for a lost email address, please follow these steps:
Carefully review the list of possible recovery actions in this FAQ entry.
Determine which of those actions you wish to perform. For lost email accounts, our failure to contact the current address must be one of the actions.
Email us from the new email address you want to use. In your email, specify a list of which recovery actions you wish to perform. Make sure your list includes enough actions for a successful recovery. (The default is 3 but if you customized this from the profile tab, you'll have to remember that.)
Include any documentation pertaining to the recovery actions you have chosen as attachment(s) to that email. Typically this will include a photo ID and a bank account or credit card statement.
Other requested steps will be initiated from our end as appropriate once all documentation requirements have been satisfied. After the process is complete, any personally-identifying information you provided during the recovery process will be discarded.
While completing this process, please observe the following guidelines:
Do not attempt to use an optional recovery action that you did not set up beforehand.
Do not send any documentation not specifically identified as acceptable.
Do not send documentation that does not meet the requirements.
Do not redact, crop or edit any documentation you send.
Do not ask for any exceptions to the policy.
Do not attempt to negotiate or argue with the recovery process.
The process typically takes 10-60 minutes of work on your part to complete. Although burdensome by Internet standards, it is typically not actually difficult unless there are extenuating circumstances. For example, if you gave us a fake name when you signed up, you're probably about to have a very bad day.
Due to the requirement that we attempt (and fail) to reach you through your current contact email address, recoveries of this type can take a long time, up to a week. Once the process is completed, we will update the email address associated with your membership to the one you used to initiate the recovery process. At that point, you will be able to recover your login information and regain access to our system.
Important: Because we don't know whether you're you, we will not help you complete the process. We will not give you hints. We will not tell you how many actions you have to complete. We will not give you any information about the status of the membership. In fact, you may find our staff unusually distant and/or unhelpful during the recovery process. To avoid leaking information, while your membership is in the recovery process, the only response to any inquiries you send will be automated messages indicating whether or not you are making progress toward recovery.
This is not personal, nor is it representative of our attitude toward helping our members. It reflects that most people who attempt the recovery process are trying to steal something, and those are people we have no interest in helping at all. That we helped them accidentally or with the very best of intentions won't be any consolation to the member we helped them steal from. So, we apologize in advance to our legitimate members for any "guilty until proven innocent" treatment they may receive while completing the recovery process. It's hard, and it sucks for everyone, but it's the right way to keep our members' stuff safe.
You can recover your login name (using your member email address) or reset your password (using your login name and email address) from this page on our public web site.
Here are two crucial pieces of information you need to reset your password and log in successfully:
Your new temporary password will be in your password reset email, but the change will not take effect until you click the confirmation link.
The confirmation code (used to confirm you want a reset) and your new temporary password are both in the email but are not the same thing.
To complete a password reset, you must perform all four of the following steps:
Request a password reset email from our public web site. (You can do this once per hour.)
Click the confirmation link in the password reset email. (This prevents others from harassing you by resetting your password without your consent.)
Log in to our member interface using the temporary password found in the password reset email.
Visit the Profile tab and select the "Change Password" action to set a new permanent password.
If at any point prior to step 2 you successfully log in with your old password, the password reset will be cancelled. Likewise, requesting a new password reset (once an hour has elapsed) cancels any incomplete previous password reset attempt.
The short answer is that fraudsters and thieves wrecked it for you.
While we support the notion of Tor on an ideological level, our real-world experience with Tor has consisted of extensive problems with Tor-sourced hacking attempts and an unsustainable level of Tor-sourced credit card fraud. We also encountered relentless exploitation by spammers and phishers using Tor to create throwaway accounts. (Sign up, create a site, send spam, get caught, sign up, create a site, send spam, get caught, sign up...)
We understand that it isn't the existence of the Tor network that makes these things possible, but it does make them easy, and when virtually all of the traffic from a certain source is malevolent, blocking that source can be the only option. Forcing people off of Tor at least long enough to confirm their membership and make an initial deposit may not be the ideal solution, but it's hard to argue with results.
For that reason, we restrict access to our member interface from IP addresses that are listed as a current Tor exit node. To lift the Tor restriction for your membership, you must already have a membership and a funded account, and you must explicitly request that Tor access be allowed via our assistance request system. (All of which must be done without using the Tor network.) We require manual approval to filter requests based on the common sense of a real person and protect members who don't use Tor from Tor-based brute force attacks on their password. We charge a nominal fee ($1.00 -- waived for subscription members) to reflect the manual nature of the review.
If you know of a reliable way for us to distinguish a handful of good people amidst a throng of would-be criminals in an environment that's raison d'être is to make distinguishing people impossible, please let us know. So far, making sure we already have a relationship with the good people is the best we've come up with.
Note: if your IP is operating a Tor exit node with a policy that allows access to our system, it doesn't matter whether you are using Tor to access our system or not; if traffic originates from a Tor exit node, there is no technical way to distinguish whether or not it passed through Tor. (If there were, it would seriously undermine Tor.) For example, the limit will still apply if you run a Tor exit node but bypass it to access our system. Similarly, if you use a VPN service that allows its customers to run Tor exit nodes, your VPN server's IP may be listed as an exit node even if you are not personally running one. These are all situations that can be addressed through the approval process.
Completely separate from that, we also have concerns about reports of unscrupulous Tor exit node operators diverting TLS connections. This is a real thing; I have personally experienced a case where using a particular exit node led to TLS certificate mismatches when accessing a site where I knew no such mismatch existed. You should think carefully about passing any secure information through the Tor network.
If you are running a Tor exit node on your IP, even if you aren't using it to access us, you'll have to cut back to relay-only long enough for the change to be picked up by Tor's published server list before you can sign up or log in. If someone else is running a Tor exit node on your IP address, you'll need to either work with them to do so or use a different IP address to access our system and request approval.
To make sure you receive automated system emails from us (including signup confirmations, password resets, account balance warnings, domain renewal notices, and other automatic service-affecting messages), make sure you are allowing email from notify@NearlyFreeSpeech.NET.
To make sure you receive any handwritten emails from us, make sure you are allowing email from support@NearlyFreeSpeech.NET. Finally, each support ticket is assigned a unique email address @support.nearlyfreespeech.net (but we don't get too many reports of those being blocked).
We won't send you any spam or unnecessary messages from any of these addresses.
If you're not receiving email from us, the first thing to check is your junk mail folder. Since our system is highly automated, junk mail filters occasionally incorrectly flag the messages it sends as spam. If you don't find them there, check your junk mail settings. Some email providers make it very easy to block a sender and silently delete such messages, making it very hard for you to figure out later that the sender is blocked.
If you're still unable to resolve a problem receiving email from us or our system, please feel free to contact us. Ironically, you'll probably have to do that by email, but if the problem is with receiving automatic messages, we'll have a real person write back. Write to us from the email address you're having trouble with, and we'll look up the fate of any messages we tried to send there. If there's a problem on our end, we'll fix it. If there's a problem on your end, we'll try to find a way to provide you with the relevant log entries so you can ask your email provider what the heck is going on.
Our login recovery process applies in very specific, rare situations:
You have lost both your login information and access to your email address.
You have a two-factor authentication configured, your second factor is lost or broken, and you don't have one-use recovery codes saved.
We determine that control of a membership and the associated email address have been hijacked or transferred to someone other than the named member.
To recover access to your membership in these situations, we offer various recovery actions, and a certain number of them must be completed successfully. The login recovery process is very onerous (by Internet standards, anyway; it's not really that difficult), and since its goal is to prevent illicit membership access, you will probably find that we are not very helpful while you are completing it.
These recovery actions can be performed by any member at any time:
You provide a legible, unredacted image of a currently valid government-issued photo ID matching the legal name on the membership. Examples include a driving license, passport, or state-issued ID card. All IDs are considered on a case-by-case basis, but a good rule of thumb for whether a particular photo ID will be acceptable is whether it shows your date of birth and whether you can go to prison for forging it. (Note: Most school-issued IDs do not meet our requirements.)
You provide a legible, unredacted image of a preprinted statement showing a transaction matching the date and amount of a recent deposit to an account on your membership and the (personal or business) name we have on file for the corresponding account. This usually means a bank or credit card statement. PayPal provides downloadable monthly statements that you can use, but you will typically also have to verify your address as described below. Email receipts and screenshots (e.g., from PayPal or us) are not acceptable.
If (and only if) you lose access to your email: We try and fail to contact you via the email address we currently have on file for your membership. (This one may take a long time.)
If (and only if) you lose your configured two-factor authentication device: We successfully contact you via the email address we currently have on file for your membership.
These optional actions must be set up in advance from the profile tab in our member interface to be used for recovery:
You complete SMS verification. (Requires SMS to be configured in advance.)
You complete two-factor verification. (Requires two-factor authentication to be configured in advance.)
You correctly answer your pre-set security question. (Requires a security question and answer to be configured in advance.)
You use an SSH key to create a file with a specific name on one of your sites hosted here. (Requires an SSH key to be configured in advance and that you have access to at least one currently accessible site hosted by us. Caution: If you are out of funds, your sites can't be accessed!)
The default number of actions required to recover a membership is three, but this can be customized from the profile tab in our member interface to make recovery (and consequently hijacking) more or less onerous.
If (and only if) you choose to provide both a photo ID and an account statement, then at least one must display the same official mailing address as that shown on the corresponding account. If neither does, you must additionally provide address verification, typically a utility bill, lease, or property tax bill matching the account address and the surname or company name. The address may be current or contemporary with the deposit. If you provide either a photo ID or an account statement but not both, you can skip this requirement.
The third and worst case scenario is that you have two-factor authentication configured that isn't working and you didn’t save any one-use recovery codes and you don't know your login and password and your member contact email address isn't working. This case is so spectacularly unlikely that even if your recovery settings are lower, you must complete all possible verification steps to regain access to your membership. Seriously, don't let this happen.
Unfortunately, the vast majority of "I lost all my information, please make an exception to your security practices and let me in" requests we receive come from people trying to gain illicit access to someone else's membership. NearlyFreeSpeech.NET takes the security and privacy of our members' services very seriously. Our members know that we are serious about protecting their privacy and security. That's at least part of the reason many people choose us. They expect us to live up to that in such situations so that when they emerge from it, they can be supremely confident that their membership can't be hijacked by the first person who comes along with a good story. Consequently, we automatically construe any attempt to convince us to make an exception to our standard practices as an attempt by an unauthorized party to socially engineer illicit access. This includes threats, attempts at negotiation, sob stories, and everything in between.
If you are a current member of our service and you log in successfully with your correct member login name and password, and then you get redirected (possibly after seeing a "click here to continue link" flash by) to the same login page again without any red error messages, this indicates that your browser did not accept the cookie our site sets to indicate you are logged in.
If this happens, here's what to check:
Make sure that your browser is accepting cookies for members.nearlyfreespeech.net. This can be affected by your browser security settings as well as third-party Internet security software. (When testing this, we recommend you start from a known point by first deleting any cookies you currently have for our sites.)
Verify that your computer's system clock is set to the correct time and time zone. Unlike other sites -- some of which want to track you for years -- our cookies last only a few hours to protect your privacy. As a result, even small-scale system clock and time zone issues can make your computer think our cookies are already expired, even though it will happily accept cookies from most other sites. (Note: Clocks that are 12 or 24 hours off can be particularly hard to spot.)
To help debug these issues, try logging in from a different browser on the same computer. If that works, it tends to indicate a browser issue. If it still doesn't work, that suggests a systemwide issue like security software or a clock problem.
First, if you are having trouble logging in, make sure this is the exact error message you are receiving. There are several other things detailed in this section of our FAQ that can cause problems logging in, but they each display a different message.
To prevent people from using incorrect login attempts to gain information about your membership or our system, this message is intentionally vague. However, if you see the "login information is incorrect" error after attempting to log in, our system will send an email to your member contact address with more detailed information about the failed login attempt. That information will include whether the problem is with the password, or (if you are using it) two-factor authentication.
If the problem is with the username, our system won't know who you are and can't send the email, so make sure to check for typos in the username. If you're not sure about your username, you can request that our system verify it for you.
If the email refers to a problem with two-factor authentication or "secondary auth," that typically indicates that you have a two-factor device configured for your membership, but that you didn't enter an authentication code from your device, used the wrong one (perhaps one for another service), or waited too long to login after generating it. If your two-factor device is lost or broken, you can use previously-generated one-use recovery codes to log in. If you don't have any one-use recovery codes saved, you'll have to go through our login recovery process.
If the email indicates the problem is with the password and you're not sure you have the right one, you can request a reset. When using temporary passwords generated by our system, the most common problems are:
Not confirming the reset before trying to use the new password. (Make sure to follow the instructions in the message.)
Hard-to-discern characters in the password, like 1, l and I, or 0 and O.
Extra whitespace characters before or after the password (especially if using cut and paste).
Entering a confirmation code in the password field. (They are not the same.)
We don't know what your password is, and there is no way for us to retrieve it. If a particular password is giving you trouble, even if you're sure you know what it is, your best option is often to request a reset anyway. (You can do this up to once an hour.)
When you enable two-factor authentication, you are supposed to generate and securely save one-use recovery codes. This situation is what those codes are for; they are used in lieu of codes generated by your two-factor device. As long as you have them, you can use one code to log in as normal and two codes to remove the two-factor device from your membership. Then you will be all set.
If for some reason you don't have those codes, you will have to complete our login recovery process.
To start that process, please send a message to support@nearlyfreespeech.net from the contact email address associated with your membership indicating that you want to complete the login recovery process to generate additional recovery codes.
Assuming you contact us from the correct email address, our system will send you a response listing which recovery actions are configured for your membership and how many of them you must complete, along with more specific instructions about how to proceed.
If, for some reason, you have lost your two factor device and access to your email at the same time, you're probably screwed, but if not you must do login recovery to update your email address first. We will not process recovery requests related to two-factor devices from email addresses other than the current member contact address.
You can ask our system to send a message to the email address associated with your membership telling you what that address is by visiting the login recovery page.
Please note that due to our privacy policy we will not, under any circumstances, disclose a membership's email address directly. The recovery form is the only way to request this information, and the recovery form will only send the information to the existing member contact address, so for this to be successful, you'll still have to find that address, and it has to work.
If you know what your contact email address is but you can no longer access it, or if you have no idea what the address is and cannot find our recovery emails, please see this related entry.
Memberships are held by individuals and have that individual's name on them. Our policies strictly forbid both sharing memberships and transferring your membership to another person. (It is, however, quick, easy and allowable to transfer an account from one membership to another or to share an account between multiple memberships when appropriate.)
If you share or transfer control of your membership, we will eventually detect that, and the membership will be suspended. Murphy's law guarantees that this will happen at the time that is most inconvenient and problematic for you. If you're reading this entry, that time is probably now.
If you are the named member, you can restore access to a membership suspended for this reason by contacting support@nearlyfreespeech.net from the email address that was on the membership prior to any fraudulent transfers, and completing all of the following steps:
Confirm that you are the person named on the membership.
Provide a legible, currently-valid government-issued photo ID matching the name on the membership.
Confirm that you understand that your membership is in your individual name and may not be shared or transferred.
Confirm that if you wish to transfer an account or any of its contents to another person, you (and they) will follow all of our policies in doing so.
If you do not have access to that email address, or if that email address does not belong to you (for example because someone else created a membership in your name despite the bold print warning not to do that), you must additionally complete the verification steps for a lost email address.
If you are not the named member, and someone else gave you control over their membership and it was subsequently frozen as a result, you will not be able to complete this process. Only the named member can do so. Your only recourse is to find them and obtain their assistance. This is true even if they quit, got fired, moved away, were voted out of office, broke up the band, divorced, went to jail, graduated, made a vow that forbids use of technology, whatever.
Please do not contact us asking for exceptions or special treatment. This situation only occurs as a direct result of violating our Terms & Conditions of Service (and the bold-print warnings presented at signup), and any problems that result are entirely self-inflicted.
Please also be aware that as of September 2017, if you have violated our policies around memberships and if that violation causes any problems or extra work for us we may assess a $50.00 fee to cover the time we spend dealing with the resulting mess.
When you sign up, we send a signup confirmation email. If that message bounces, then the membership is usually deleted within a day.
If the signup confirmation email doesn't bounce, but no one responds to it, it may linger for up to a week before being deleted.
If someone replies to a signup confirmation email from the address we sent it to, and the membership has never been accessed, we will manually delete the membership as time permits.
We will not manually delete a membership associated with one email address in response to inquiries from any other email address.
If you signed up with the correct email address, but that address is no longer valid, please see this entry instead.
If your ISP changes your IP address, or you use Tor or another service that causes your web request to originate from multiple IP addresses, you may find that our system prompts you to log in again whenever your IP changes.
This is a security measure designed to prevent session hijacking. By default, all your requests must originate from the IP address you logged in from. However, if your IP address changes frequently, constantly logging in can get super annoying. So this behavior is configurable.
To review or change your session protection settings:
In the Details box, find the Session Protection line.
You can see the current setting on that line. To change it, select the Edit link.
You must log in from a stable IP address to make this change. This may require using an alternate connection, such as a cell phone data plan, access at work or home, or a public library.
The default setting is High, which is fine for most people. We recommend thinking long and hard before choosing a setting below Medium.
The status of your support issue is indicated on the "Current Status" line in the issue summary on the support tab. Here's an explanation of the terms you might see there:
Available
This means an issue has been created through our secure support system, but has not yet been picked up by or assigned to a specific individual yet. "Please hold for the next available representative."
Received
Since we can't provide membership-private information in response to email requests, issues that are created from emails sent to support@NearlyFreeSpeech.NET are marked as "Received" instead of "Available." Issues like this will usually have to be resubmitted or confirmed by logging in to your membership (provided you are eligible for email support), but we'll read them first to make sure they don't say, "Help, I can't log in to my membership!"
In Queue
Once a specific person has reviewed and claimed your issue, it moves to the "In Queue" status. Issues in this status are typically worked on in the order in which they are received or updated, subject to the issue's requested priority level and our best judgment.
Pending Auto-Close
Once we have responded to an issue, we will usually consider it resolved unless you reply back within 24 hours with more information. During those 24 hours, the issue will be flagged as "Pending Auto-Close" in our system.
No Subscription
This an issue that would qualify for individual support under a subscription membership, but the person who submitted it has a baseline membership that does not include individual support, so we cannot proceed with it. If you obtain a subscription within 24 hours, the issue will be automatically reactivated. Otherwise, it will time out and our system will close it. (You can also retrieve the text of an issue in this status using the View Support History action from the Support tab, for example to repost it to our forum.)
In Progress
It's relatively rare to see an issue in this state, because most issues are resolved quickly and move straight from "In Queue" to "Pending Auto-Close." However, if an issue requires an unusually large amount of work to complete, we try to move it into the "In Progress" status while we work on it to let you know that. This most frequently happens with things like installation of software into our CGI environment.
Awaiting Response
Sometimes we can't allow an issue to be closed until we hear back from you. Usually that happens when we open the issue instead of you. In such cases, the issue moves to "Awaiting Response" until we hear from you.
Pending Verify
After we've established that a "Received" issue doesn't involve logging in, we'll send you a message telling you to log in and confirm it. Once that's done, your issue moves to this state. If you don't confirm it within 24 hours, it'll close and you'll have to start over.
Waiting
This issue was received or updated outside our normal hours. Once our standard support hours arrive, it will automatically change to some other more appropriate status. (During the day, our system only checks its watch once per minute, so a new or updated issue might linger as "waiting" for up to a minute before jumping over to a more active status.)
Blocked
Blocked issues are awaiting response or information from a third party (i.e. not you and not us).
Sleeping
Sometimes we need to defer an issue for a specific amount of time. For example, we may say "we'll check this tomorrow afternoon to make sure it is still working." In such cases, the issue is marked as "Sleeping" until the appointed time arrives. Sleeping issues provide their own built-in alarm clocks.
Completed
When happy issues reach the end of their life with us, they go away to live at the "Completed" farm where they are free to run and frolic all day long.
Killed
People (usually non-members) occasionally send email to support or abuse like "Please take down the so-and-so site! It offends me." The resulting issues do not get to go live on a farm upstate.
To give you the strongest and most stable possible foundation upon which to build your site.
To minimize the amount of work you have to do to keep your site's infrastructure up-to-date and secure.
To do both while giving you as much flexibility as possible to build what you want.
To meet those goals, we divide software into four broad categories, two that we're responsible for and two that you're responsible for:
We're responsible for: The operating system, system tools & utilities, programming languages, and their core libraries.
We're responsible for: third-party libraries and modules that are particularly common, popular, or that require regular updates.
You're responsible for: third-party libraries and modules we don't provide that your site needs to work properly.
You're responsible for: your site's application code and data.
#1 and #4 are clear enough, but the demarcation line between #2 and #3 is always a tricky balancing act. The lower-level a module, or the more security implications it has, the more likely it becomes that we should provide it. If a module requires customization, imposes restrictions, or often has backward compatibility issues, you should provide it.
This entry discusses how you can install third-party libraries modules yourself for the most common languages and how to request that we install things when appropriate.
Node.js
We provide the node binary and the npm and yarn package managers. You can use these to install needed dependencies to the current directory. (E.g., npm -g will not work.)
Perl
You can use local::lib to set up a per-site repository that will work with CPAN to allow you to obtain and use exactly the modules you want. We do centrally install modules from the CPAN archive with appropriate justification. In this case, there is an additional requirement that the module's built-in tests pass in our environment.
PHP
We provide PHP binaries and core extensions (both built-in and from PECL). We add extensions only if they are of great general interest. We recommend the use of Composer or a similar tool to set up and manage your application's PHP environment. This will ensure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system. You may also build and use extensions we do not provide.
Python
We strongly recommend using virtualenv or a similar tool to set up and manage your application's python environment. (Note that Conda does not work well on FreeBSD.) However, unlike other languages, Python's performance degrades as more modules are added to its central library; you will usually get better performance and a more stable site if you use a virtual environment with exactly (and only) the modules you need, rather than diving into the deep pool of modules provided by our system. Consequently, we can centrally install PIP modules if (and only if) they are of great general interest or are especially difficult to build properly. (Numpy, we're looking at you.)
Ruby
We provide Ruby binaries and the gem package manager. We tend not to provide many centrally-installed gems. We recommend setting the $GEM_HOME environment to a path of your own (e.g., /home/protected/gems) and using gem or bundler or a similar tool to set up exactly (and only) the modules you need. This will ensure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system.
Others...
For other languages or general-purpose utilities, we rely on the FreeBSD ports collection, which contains 27,000+ software packages. If a package is of sufficient general interest (and not in one of the prohibited categories below), we are generally able to provide it.
If you have questions about how to perform per-site module installation for one of these languages, please review the support tab for your support options.
To request that we centrally install a new software package, please submit an Assistance Request. (Make sure to follow the instructions on that page.)
When we install software, we require that the requested software package have some applicability to web hosting and that central installation of the software will not interfere with others' use of the service. For example, we cannot install the following categories of software:
games
client applications (like email or IRC clients)
GUI applications
applications (like content management systems) that require extensive per-site customization
software that requires a commercial license to use
Apache modules
customized packages or nonstandard configurations
packages with specialized installation or configuration requirements
A system problem is a malfunction in our systems or network negatively affecting previously-working production services that requires the manual intervention of our system administrators to resolve.
That is very dense, and each part has a specific meaning. Here's how it breaks down:
A malfunction: Something is broken.
In our systems or network: What's broken is something that we maintain as part of the services we provide.
Negatively affecting: It actually has to be causing a problem.
Previously working: It used to work, and then it broke. If XYZ has never worked, it is not a system problem that it is currently (still) not working.
Production services: Issues with test sites and beta services can't be treated as system problems.
That requires the manual intervention of our system administrators to resolve: We have to use system-level access that you don't have to fix it. Even if you had perfect knowledge about what the problem is and how to handle it, you still wouldn't be able to fix it yourself.
Typical system problems include:
crashed servers
downed network links
routing problems inside our network
DDOS attacks on sites other than your own that are negatively affecting you
extreme misbehavior by sites other than your own causing "spillover" problems that affect you
A few examples of things that are not system problems include:
Expired domains.
Not knowing how to do something.
Buggy or broken code on a site.
Any problem inside a running member MySQL process.
Performance problems arising from your own inefficient or excessive resource utilization.
Attacks of any sort specifically targeting your site.
In most cases, you won't know what the specific system problem is. You have to detect them by the effects they have on your service. Some example effects of possible system problems would be:
A web site is not responding or produces a system error message that does not include a link to a FAQ entry explaining the error and what to do about it.
A MySQL process is unreachable or drops connections when accessed with correct login/password credentials.
Our DNS servers return an error or no response at all for records that are correct in the member interface.
Our member interface returns an error message while trying to perform a valid function.
However, situations do require interpretation. Sometimes the same effects can occur from both a system problem and something that is not a system problem. For example, if your website's domain name does not resolve because our DNS servers all crashed, that would be a system problem. If your website's domain name does not resolve because it is expired, that is not a system problem.
Our recommendations for who should obtain subscription memberships are outlined on our public site but in brief, unless either the services you obtain from us are mission-critical and need the fastest possible response regardless of circumstance or you plan to contact support on a regular basis (more than twice a year), we recommend the baseline membership.
If you do not have a subscription membership, but you do have a question, the best option is usually our community support forum.
We'll usually answer the same question for free in the forums that are covered by a subscription membership, because when we answer a question in the forums, everyone can see and benefit from the answer, not just the asker. (To get the best results from our forum, make sure you're helping the system work by demonstrating in your forum post that you've already searched the forum for people who have asked the same question in the past.)
We provide the option of a subscription membership to reflect the fact that the time of one or more professionals is being spent exclusively and privately on your issue.
So, in most cases, if you're paying for a subscription membership that you use to ask simple questions, you're not paying to have the question answered, you're paying to make sure a skilled professional is available to answer your question, and to have the answer provided privately.
Naturally there are exceptions, particularly if you need us to do something, rather than answer something. Once you get outside the realm of answering a question into an area where we're expending professional time investigating or explaining something on your behalf, the subscription membership is the most appropriate way for us to recover the associated costs.
This indicates that the behavior you reported as a system problem is actually the correct, direct result of how you have things set up. That's actually good news, because it means that it is under your control and you can resolve it on your own.
However, this response often confuses people, because if someone knows that they set something up a certain way, they usually don't report it as a system problem. So receiving this response typically indicates that one of the following has happened:
You may have configured something and then forgotten about it.
Something may have been configured unintentionally. (E.g. by accidentally clicking a button in the member interface or misreading a form field.)
A configuration may not have the effect you expected it to.
It may be a default setting that isn't actually a fit for your situation.
Here are some common examples of "Works as Configured" issues:
"My site returns 'connection refused.'" (The site is set to use a custom web server,
but no custom web server is set up.)
"It says my SSH login is incorrect." (The site or membership is set not to allow SSH.)
If the issue is related to a web site, the "Troubleshoot Site" action (available from the Actions box on the Site Information panel for the site) can point out a lot of configuration issues that cause unwanted behavior.
It's often also helpful to go through our member interface and review anything in yellow, orange, or red text, or anything that says "Deprecated," "End-of-Life," "Obsolete," "Dangerous" or similar.
If you're unable to find the requisite setting to control the undesirable behavior, you may wish to post about your issue in our forum or, if you are a subscription member, open an individual support issue. (Although if you are a subscription member, "works as configured" responses are auto-converted to individual support requests.)
We provide a number of support options designed to meet various needs.
Self-Help Options
Self-help options are always free. They include:
This FAQ. It contains a lot of detailed information about how our service works and how to do various things. This is a one-way communication channel where we provide you with information we think it is important for you to know.
Our Member Wiki which contains tons of useful information contributed by our members about what does and doesn't work on our system. This is an "all ways" communication channel, since any member can add or edit information.
Community Support Options
Like self-support, our community support forum is free and available to all members. In addition to our staff, lots of awesome volunteers hang out here, so this is a great way to get a fast answer to a simple question. (And often complex ones as well!)
Special-Purpose Professional Support
Like self-help options, our special-purpose support options are free. Unlike self-help, the scope of the special-purpose professional options is very limited.
If there is a system problem affecting your service, you can open a free System Problem report. This isn't really a support option, it's a one-way communication mechanism you can use to tell us about something you believe is a problem.
System problem reports are technology-limited to various predefined responses, so it's not a way we can provide you with information.
System problem reports have their own FAQ entry.
For certain pre-determined tasks that need us to do something on your behalf, we have free assistance requests. The opportunity to open assistance requests is often context-specific, but there is an index of them on the Assistance Request page.
General-Purpose Professional Support
If you would like to ask questions or get personal support from our staff in private, we provide that service through an optional, extra-cost subscription membership. If you have one, you can open a support issue. If your question is within the scope of our support, we'll do our best to help out. Keep in mind that our service is do-it-yourself in nature, and a few dollars a month doesn't change that; this feature is used to request information from us to help you do something, it is not used to get us to do things for you. "Can you help me figure out why my site is slow?" is something we may be able to help with. "Please fix my site's code so it isn't slow" is not. Support provided through our subscription membership is also "best effort." We'll do the best we can to help out, and we're pretty good, but we're neither omniscient nor omnipotent, so we can't guarantee any particular outcome or result.
We strongly encourage members to make their own backups. However, sometimes that just doesn't work out, and people need to know what we can help them recover.
Recovering deleted files from a site
If you've accidentally deleted a file or files on your website, or you want to roll back to a recent backup, you may be able to fix that yourself. On the ssh server, the /home/.zfs/snapshot directory allows you to access historical snapshots of your site. Snapshot names are 12-digit numbers based on the date and time the snapshot was created, in the form YYYYMMDDHHMM. For example, if a snapshot is named 202401021200, then it was created on 2024-01-02 at 12:00 UTC. A site may have up to 60 snapshots covering the past 30 days, depending on how large the site currently is, how fast the site's content changes, and how long ago it was created.
You can copy individual files out to the live site:
The --dry-run flag will cause rsync to tell you what it would do instead of doing anything, so you can make sure the behavior is what you expect. Once you're sure you're putting the right files in the fight place, run rsync without --dry-run and it will perform the operation for real.
The rsync command also supports --delete and --force flags (among many others), which may be useful to make sure there aren't other stray files laying around. But these flags can also be very dangerous; if the command isn't exactly right, they may delete something other than what you intended.
Recovering sites or MySQL processes that have been completely deleted
We will invest the time to determine what can likely be recovered and how much it will cost to do so. There is a fee for us to produce this estimate unless you have a subscription membership.
Based on the cost and expected results, you can decide whether or not to proceed with the restore and make sure you have the necessary funds available in your account.
If you decide to proceed, we will debit your account for the cost and perform the restore.
Rolling back a MariaDB 10.x process to an earlier state
As with deleted sites and MySQL processes, use the Attempt to recover deleted content assistance request. The process is very similar, although the costs are much, much higher. Further details are under the appropriate heading on that page.
Other deleted content
Registered domains can be recovered for a little while after they expire.
Removed DNS or email forwarding settings cannot be recovered.
In short, this means that the issue you reported did not meet the definition of a system problem.
Most people submit system problem reports with a good faith belief that they're reporting a problem with our system. So it can be surprising and frustrating to see that we did not agree with their assessment, and we totally understand that.
We take all system problem reports seriously. When we close one as not a system problem, we're not blowing it off, we're not just doing it to be jerks, and we're not trying to pretend a problem doesn't exist. We investigate the issue enough to figure out what's going on. Typically, we can see exactly what the problem is, and it's not a system problem. However, the generic "not a system problem" response doesn't provide that information. (To understand why we do this, please see this FAQ entry.)
We find that members sometimes submit invalid system problem reports if they have a misconception about what such reports are for or how they work. One such misconception is that system problem is a synonym for important. This is not the case, and attempting to report something as a system problem because it's important to you is a recipe for frustration. The report will be closed, everyone involved will be irritated, and you will have to start over with lost time and an even higher frustration level.
We also find that members are sometimes confused about which support mechanism is right for their situation. System problem reports are not a way to get support, free or otherwise. If you want the fastest possible response about something important to you, then maintaining an active subscription membership is by far the best way to obtain that. If you're not sure which support mechanism is right for your needs or you prefer not to pay for support, try asking in our member forum first.
Another difficulty we encounter is an inappropriate definition of "system problem." Anything that doesn't work as expected, this theory goes, qualifies as a "system problem" because the system is not working as expected, and that's a problem. This is not the case. We have meticulously defined exactly what constitutes a system problem. Please ensure you're using our definition when reporting a system problem since that's what we will use when responding to the report.
Here are a few examples of common issues that may appear to be system problems but aren't:
I cannot log in to ssh. (Member is using the wrong login credentials or has a local firewall issue blocking access.)
I get permission denied when trying to upload. (Member is trying to upload to the wrong directory.)
My site is down, but I can still see (other site). (Member's domain is expired, or an Internet network between us and their ISP is having a problem.)
My email forwarding is silently dropping email. (Member's email is forwarded properly but dropped at the far end; we do not silently drop messages -- they bounce, get quarantined, or get forwarded.)
My XYZ suddenly broke, and it must be a system problem because I haven't touched it in ages. (XYZ depends on ABC, which was discontinued by its developers years ago, and we finally had to drop it after warning we would well in advance.)
Any one of those could be critically important to the person reporting them, but even if that's true, they still aren't system problems and can't be addressed through the system problem report facility.
If you do get a "not a system problem" response, your next course of action -- if you can't figure it out on your own -- should be to contact us through one of our member support options. This is true especially if you're sure we got it wrong because, at that point, you need to talk to someone, and system problem reports aren't a way to do that.
Because the system problem report feature is intended only to provide a no-cost mechanism to allow our members to let us know about malfunctions affecting their service, not as a general-purpose support mechanism, the responses we can generate are extremely limited. After we close your system problem report, you will receive an autoresponse based on our findings.
Problem Resolved
We have resolved the reported system problem. Yay!
Not a System Problem
We investigated the report and found that it was not a system problem. This response has its own FAQ entry.
Works as Configured
We investigated the report and found that at some point you set up or requested the specific behavior you have now reported as a system problem. This response also has its own FAQ entry.
No Problem Found
We investigated the report and we were unable to reproduce the problem described. There are two basic ways this can happen:
The problem went away by itself before we got to it. Our systems are designed to auto-recover many types of failures. A DDOS attack affecting it may have stopped on its own. Many Internet problems are intermittent and short lived.
Everything is working fine on our end and the problem is elsewhere, like a problem between your ISP and our network.
Beta Problem Exclusion
The problem you are reporting is related to your voluntary opt-in use of beta or experimental services. Problems arising from the beta/experimental nature of these services are specifically excluded from the definition of a system problem.
Insufficient Information
We need more information to investigate the report. This most often happens if someone says "my site is down" but has more than one site and doesn't specify which one it is, or something similar. You can reply back with additional information and we can give it another check. For some guidelines about providing more information, please see this FAQ entry.
Problem Identified
We have confirmed a problem related to the report and resolution is in progress. (These are rarely sent; they are used only when resolution is expected to take a particularly long time so you'll know we're working on it.)
Duplicate
The reported problem is a duplicate of a previous report or a problem that is reported or documented elsewhere. To avoid duplication of effort, this report is being closed. If you didn't submit the report more than once, check main support tab or the offsite status page to see if more information is available.
If you get a response that indicates that no problem was found or that the issue is not a system problem, then you may need more information to help understand what's going on. Although it may be tempting to reply to the autoresponse, don't do that! Messages to closed reports are not seen by human beings. We would recommend following up through one of our support options.
We love feedback! You're welcome to send email to feedback@nearlyfreespeech.net with any thoughts, comments, or minor bug reports about our service.
If you send a message to this address, we will definitely read it.
However, feedback email isn't a way to obtain member support; if it looks like your message would be better suited to one of our support methods, we'll try to convert or redirect it as appropriate so you can decide whether or how you want to follow up on it.
As long as you don't have any open issues that need points, you can select the "Cash Out Support Points" action from the Account Information panel for your account.
Support points are also automatically cashed out when a membership is closed.
Our official Twitter handle is @nfsn. However, as of 2023, it is functionally inactive.
We had already decided Twitter was a raging dumpster fire when its new ownership started trying to drown it with gasoline. Twitter's apparent purpose is to manufacture rage and induce conflict. We don't think those are useful properties for a communication channel. Nor are they well-suited to working together to find and solve problems. As a result, Twitter is not a method we use to interact with our members.
We always value what our members have to say. If you want to share your thoughts with us or need help with something, please use our forums or check your options on the Support tab of our member interface.
(Yes, we know about "the artist formerly known as Twitter." No, we're not calling it that.)
The most important thing to know about system problem reports is that if you're encountering a system problem and you think we don't already know about it, we want you to report it. Providing a reliable, high-quality service is really important to us, and system problem reports are an invaluable way for us to find out about subtler problems that can be hard for us to automatically detect.
The second most important thing to know about system problem reports is that if you submit one, you won't get an answer. System problem reports are essentially a one-way channel of communication. They are a free way for you to provide information about system problems to us, not vice versa. A decent rule of thumb is that if there's a question in your system problem report, or if you're expecting any response more thorough than "Thank you for your report," you're probably not reporting a system problem.
System problem reports are only one tool in the toolbox of options we provide for you to contact us. Like most tools, they are not appropriate for every situation. Also like most tools, in order to get good results, it's important for you to make sure that it's not only the right tool for the job, but also that you use it correctly. And like most tools, if you use it in the wrong situation, or use it improperly, the outcome will be bad, if not downright painful. Members occasionally torture themselves with a system problem report because it's the wrong tool for the job but they insist on using it anyway; we hate to see that.
Reporting a system problem is serious business, like pulling a fire alarm. We understand that mistakes happen, but our system does evaluate your past system problem reports when determining whether to allow you to report new system problems as well as what priority to give them. For this reason, we strongly encourage you to investigate the situation to the best of your ability before reporting a system problem. There are distinct "boy who cried wolf" consequences for people who repeatedly misuse the feature.
Once you submit a system problem report, we will typically receive and investigate it very quickly. Although our stated response is "as soon as possible," many system problem reports are closed within a few minutes of being created. But we do invest the time necessary to check out the report, so it may take longer.
After we've finished investigating the report and doing whatever we need to do, if anything, we'll close the report and you'll receive an auto-response.
It will not satisfy your curiosity, and it will never answer any questions or provide guidance about actions you should take. To understand why this is, please see this FAQ entry.
That's pretty much that. Once we've closed the report, it's closed. You can't reply to it and we can't respond further or in more detail. If you want or need more information, you'll have to use one of our member support options to get it, such as paid support or the forum.
In all cases, we recommend following our troubleshooting tips before opening a system problem report, and writing a system problem report that shows you did so. The best system problem reports do these two things:
Clearly describe the problem, including all relevant information.
Demonstrate that the definition of a system problem has been met, or, if you can't be sure, at least show that you know the definition and reasonably believe it fits.
Making sure you cover both of those will help to ensure you get the quickest, most accurate, and most helpful resolution of your system problem report.
Assistance requests allow us to perform specific, predefined actions on your behalf that our member interface does not allow you to perform for yourself.
Processing of assistance requests is highly automated. In general, they receive one of three responses:
a confirmation that the request has been completed,
a response indicating that the request was unsuccessful,
a response indicating that the request is out of scope.
Success or failure notifications may be accompanied by a brief error or diagnostic message based on the type of request.
An "out of scope" response means that whatever you asked or requested was not something that can be processed through the automated assistance request system.
If you receive an "out of scope" response, no further reply you make to that issue will be seen or acted on by anyone unless you have an active subscription membership or obtain one within 24 hours.
In general, if the responses "completed" or "unsuccessful" do not fully address your concern, an assistance request is probably not the correct support mechanism.
The other options for member support vary depending on what type of membership you have; please see this related FAQ entry for details.
Unless you're satisfied with the sort of people that mumble at you from prewritten scripts that may or may not be related to the question you asked, tech support is a very difficult job that requires extensive technical and people skills, almost constant training, and a lot of dedication.
The money to pay people to do that hard job has to come from somewhere. So all web hosting companies charge for support, and there are five ways to do it:
Operate at a loss, backed by investors, trying to slurp up customers by giving away service, including support.
Offer "free" services, including support, by inserting ads into your hosted content.
Hide the cost of "free" support by charging higher prices for other services and including support, like a "free" prize in a cereal box.
Hide the cost of "free" support in a flat monthly fee that is completely independent of usage.
Openly and honestly charge for the service of support.
Few companies more than a year old use strategy number 1, because it's really expensive and the market is too competitive; they either change or fail. It's still charging for support, it's just charging the investors instead of you.
Option 2 can work if everyone involved has low enough expectations. But they are charging their customers for the cost of providing you support. You're just not their customer.
Most companies choose options 3 and 4. So they may claim it's free support, but it can actually be quite expensive, especially if you aren't using it.
As a "pay for what you use" service, we use option 5. If you're willing to commit to not asking for support, you shouldn't have to pay for it. So our model recovers the costs of support only from the people who want it. This has two major effects.
First, people who never or only rarely use support can save substantially over the long term.
Second, people who want support beyond what the forum offers may pay somewhat more, or at least somewhat more visibly, for it here than they would somewhere else, since the cost of providing it to them won't be subsidized by a bunch of other people who pay the same amount but never use it. It's hardly expensive as monthly web hosting fees go and we do our best to make the support we provide worth the price.
Even though we investigate all system problem reports sufficiently to understand what the problem is, we provide only generic responses.
This raises an obvious question. If you're reporting a problem and we know what the problem is, whether it turns out to be a system problem or not, why don't we tell you what we found?
We've actually tried that in the past, and it was a disaster.
Like paid support, system problem reports are individual and private and handled by skilled professionals. However, system problem reports have several significant advantages over paid support:
Consider two people with the same problem: their site is suddenly offline and they don't know why. For both people, the cause is the same, their domain—registered somewhere else—is expired and they just didn't notice. (An understandable situation, but not anything to do with us.) At midnight, Person A submits a paid support issue and Person B submits a system problem report. Without limits on system problem reports, they get the same response but Person B gets it hours sooner and for free. That creates a perverse incentive to misuse the system.
So we built a third system that charged for system problem reports. That was also a terrible idea. (It burned down, fell over, then sank into the swamp.) If you find a system problem, we don't care how much money you do or don't have, we want to hear about it.
As a result of all that, we allow free system problem reports but limit the responses. That has worked out very well for both us and our members. (But the fourth one stayed up!) System problems get fixed promptly, and there is no benefit obtained by reporting things that are not system problems.
We no longer offer support points. If you happen to have a negative support point balance, the link to Purchase Support Points is found in the "Actions" box in the upper right corner of the Support panel. Otherwise, check out subscription membership instead.
If you've reviewed our member support options and you're not sure which one is right for your situation, we recommend posting the general, public-safe details of your situation in our Member Forums and asking for guidance. Someone will be glad to help you figure out what's the best way to go.
There are a couple of optical illusions that make it appear more expensive than it really is.
First, compared to the rest of the services we offer, the price of a support subscription is relatively high. If you want to make something look bigger, set it next to something small. (If we went in for manipulative marketing, we'd do the opposite: offer some hugely expensive incrementally better alternative that would make support subscriptions look like a bargain by comparison.)
Second, other providers tend to charge everybody for support whether they use it or not, either with a flat monthly fee or by hiding it in the cost of other services. This makes the cost of support appear lower than it is because if one person in five uses support, that person only has to pay 1/5th of the cost. But the other four are subsidizing him, getting nothing in return and there's nothing they can do about it. We refuse to do that. Our members will always have a choice.
Like the rest of our services, the price of a subscription membership is based on the cost of providing it; providing high-quality support is really expensive. And in addition to the cost of actually providing support, there are significant ongoing costs associated with making sure someone who knows what they're doing will be available when support is needed.
We've experimented with several models that offer less support at lower costs, with invariably poor results. Underfunded support leads to a soul-crushing contest to see who is more miserable: the members receiving inferior support, or the people who have to provide it. That's a game with no winners, and we won't play it. We are interested in providing support in one of two ways: really well, or not at all.
So, support costs (you) what it costs (us). We feel the subscription membership is a very good value that gives us what we need to be able to take good care of the people who select it. But what makes us really different is that we make it opt-in in an industry that usually doesn't even let you opt out.
First, we prioritize individual support requests based on the subscription member's past use of support. I.e. the less support you've used, and the longer you've been a subscriber, the higher you'll be in the queue and the faster the response time you will get. In contrast, newer subscribers and people who open many support requests may have to wait longer for a response.
Second, if you have been a subscription member for a long time but haven't needed much help, we will see that when you eventually do. Under some circumstances, we can use that to your advantage and spend extra time helping you troubleshoot an issue or digging deeper into our system to understand what's going on. When those opportunities arise, the metric we look at is how long you've been a subscriber.
Third is the philosophical reason. Most of the costs of providing you with support have been incurred before you ever seek support. Subscriptions help make sure that when you do seek support, there will be someone there to provide it, and that that person will be someone well-trained and capable of providing the best quality support possible. To put it another way, you probably don't want us to wait until you have a question to go out and recruit, hire, and train someone qualified to answer it.
We acknowledge that we can list as many reasons as we want, but asking you to subscribe to a feature the primary benefit of which is support before you need support is essentially asking for a leap of faith. When we look at a support inquiry and see that somebody made that leap and subscribed months ago, we do everything humanly possible to make them happy they did.
1pm - 9pm US Eastern time (10am - 6pm US Pacific time)
Saturday, Sunday & Holidays
3pm - 7pm US Eastern time (12pm - 4pm US Pacific time)
During these hours, we attempt to maintain an average response time of under two hours for all assistance requests and inquiries from subscription members. Complicated requests and asset transfers between memberships can sometimes take longer, and cancellations are typically only processed once a day.
We do observe daylight saving time, although we think it's dumb and should be eliminated. If you're outside the US and want to see what time it is US Eastern time, Google will tell you.
Calling these our "standard" support hours is meant to indicate that we often respond to assistance requests and inquiries from subscription members outside these hours when we are able to do so; our goal is always to respond to member issues as quickly as possible.
MySQL processes are created via the
MySQL panel of our member site. For a description of our MySQL pricing, see this page.
Within a MySQL process, you will have full administrative control and you may create as many databases as you wish. One process is more than adequate for most uses, including supporting web sites, each with multiple unrelated applications, such as forum software and blogging tools, but you may add more if you wish.
We do reserve the right to limit excessive MySQL usage that disrupts other members. MySQL is very efficient, so this is rarely an issue, although it can come up if a process is using large tables that are not properly indexed.
(For information about the difference between a MySQL process and MySQL database, please see this related FAQ entry.)
There are two easy ways to create a database inside your MySQL process. For either method, you will need the database administrator username and password. The username is the same as your member login name, and a temporary password was created and emailed to you when you created the process.
The fastest way to create a database in your MySQL process is to click the "Create a Database" action on the MySQL Process Information page for your MySQL process on the MySQL panel, and just follow the steps.
However, the phpMyAdmin tool that we provide can also be used: Choose "Open phpMyAdmin" from the "Actions" box on the MySQL tab Then log in to your MySQL process. Then choose the "Databases" tab. Next, look for the text box under Create database. Pick a name for your database and enter it in that box. Then select the Create button. That's all there is to it!
You can use this ability to set up a whole bunch of applications to use different databases in the same MySQL process, even if the applications are running on completely different sites and don't share any information.
Example: Suppose you have two sites, and you wish to run the phpBB forum software on both of them without having them smack into each other. You could create two databases, one called sitea and one called siteb, in your single MySQL process, then set the $dbname value in each site's phpBB config.php file to sitea or siteb.
(You can also use phpBB's $table_prefix feature for this purpose, but three out of four nerds agree that the two-database way is "better.")
The DSN, or hostname, for connecting to MySQL is the name you gave when you created it, followed by the extension .db. The full connection information can be found in the email sent to you when you created your database. Never use localhost as part of your database connection information.
If you need to find your DSN and no longer have this email, visit the MySQL panel. The DSN for your process appears in the first column. Clicking on the DSN name will take you to a page with more information about your process, including your default admin username.
DSN stands for Database Server Name and is sometimes also referred to as hostname or MySQL Server Name or even just server name. This is different from Database Name, which is something you choose separately for each program that uses your database (and usually create from our interface, the command line, or a tool like phpMyAdmin).
A MySQL process or MySQL server (or even MySQL server process) refers to the actual running MySQL software.
A MySQL database, on the other hand, is a collection of related tables within a MySQL process that share a common purpose, like running a forum or blog application.
A MySQL process may contain more than one MySQL database. (If it doesn't have at least one, it isn't very useful.)
MySQL processes are identified by their DSN or hostname, which is of the form example.db. You chose this when you created the MySQL process, and you can see it on your MySQL panel in the user interface.
Sometimes the term MySQL database gets misused to mean the MySQL process. This usually happens when the process only has one database. We try to avoid that usage, because it is ambiguous and confusing, and we encourage you to do the same. But it happens, so if someone says "MySQL database" and you aren't 100% sure which one they mean, ask them. "Do you mean the MySQL process itself or the database within the process?" The confusion you avoid may be your own, because you have to know which name goes where when you configure your application.
Possibly. When we created your MySQL process, we assigned a password to the 'root' MySQL user, which only works from the physical machine running the process (which no users have access to). If you have not removed that, we can reset your database password with no problem. In cases where this is all that is needed, the cost is $1 (waived for support subscribers). If you want to do this, open an assistance request and indicate you are aware of the charge. If the reset is successful, a temporary password will be emailed to you.
If you have removed our access, which you are welcome to do, then we will have to use a different approach that is very time-consuming. A professional services fee will apply. (Typically, $10-30 depending upon the amount of DBA time required.) This approach will cause downtime for your database and any sites that depend on it. The procedure is fairly safe, but there is a small risk that it might cause you to lose some or all of your data.
We strongly recommend that you use your MySQL administrator username and password only for the purpose of creating other MySQL users.
It is much too powerful to be used directly from your website or plugged into any web pages or config files! To create a new user with only the necessary privileges, see: this entry.
Please keep careful track of your MySQL passwords.
To connect successfully, use a command similar to the following:
YourPrompt$ mysql --host=example.db --user=username -p Database
Where the "username" is the database username (usually the same as your NearlyFreeSpeech.NET login, unless you have created another) and "example.db" is the database DSN you chose when creating your database and "Database" is the name of a database in your MySQL process that you have created. Using the above command line, you will be prompted for your MySQL password. The initial password was emailed to you at the time you created your process, but hopefully you've changed it since then.
To create a database in your MySQL process from the command line, use a command similar to the following:
Using the same values as the first example, this will prompt you for your MySQL password and then create a database called Database in your MySQL process. (We'll leave the task of coming up with a database name more creative than "Database" as an exercise for the reader.)
If you need to redirect input (for example to load a MySQL dump file), you will additionally have to specify the MySQL password on the command line, like so:
YourPrompt$ mysql --host=example.db --user=username --password=password Database <database.sql
You cannot directly access MySQL processes running on our network; they use private non-routable IP addresses.
However, you can use SSH port forwarding to access them remotely.
This is allowed for two very specific purposes:
Initial set up (or tear down, should it be necessary) of your MySQL database.
Routine database administration tasks.
The best guideline for whether what you are doing is allowed is whether you are doing it. In other words, no automated port-forwarded access to MySQL is allowed; it must be you personally doing whatever you're doing. If, for example, you want to back up your process, you should use another method.
Because of the large variety of ssh clients and ssh-protocol tunneling applications that exist, and the innate complexity of ssh tunneling, we cannot provide any technical support related to remote access to your MySQL database.
To use ssh port forwarding in conjunction with the industry-standard OpenSSH client, one would use a command similar to the following on one's local system (not our ssh server):
Please note that the command above needs significant specialization for use in your specific circumstances. If you are uncomfortable making the needed changes, this is not a feature you should attempt to use.
On our system, whatever method you choose needs to boil down to two SQL commands:
CREATE USER 'username' IDENTIFIED BY 'password';
GRANT ALL ON dbname.* TO 'username';
Do not specify a hostname when creating users; since we use a clustered hosting network, you cannot predict from what host a connection will originate. Also, attempts to "GRANT ALL ON *.*" will typically fail due to the lack of the FILE permission by default on admin users, and it is bad practice to grant administrative privileges to a website user. Finally, try to avoid granting ALL if you can; security is always enhanced by minimizing the privileges of website users.
The "mysql" database contains vital information about the other databases, usernames and passwords in your MySQL process used when it starts up. It is a very important part of MySQL, and your process won't start if it's removed or corrupted. Unfortunately, MySQL will let you alter or remove it without any warning or special confirmation. Don't ever do that. Because people sometimes do, our system checks on this database periodically and if it detects a problem it will report your MySQL process as "Damaged" in our member interface.
MySQL 5.0 and later versions also contain a synthetic database called "information_schema" which can be used with SQL commands to obtain metadata about your other databases. Since this database is created entirely from information about other databases, it doesn't really exist, and attempts to alter or remove it will fail.
MySQL processes may also be created with a database called "test." This database serves no purpose and can be removed if you don't want to use it.
Because we still have to retain the associated MySQL data and reserve enough resources for you to start it at any time.
To avoid being charged for having a MySQL process you are not using, you can remove it by visiting the "mysql" page, selecting the name of the process you want to delete, and then selecting "Permanently Remove Process" from the "Actions" box.
There are several causes of this error. To figure out what's going on, look for a hash sign and a four-digit error code in front of this message. E.g. "#1045 Cannot log in to the MySQL server." This code is a MySQL error code, which comes in two varieties, 1XXX server codes and 2XXX client codes.
The two most common error codes are #1045 and #2002.
Error code #1045
This typically indicates a problem with the username/password combination provided. That's definitely the first thing to check. It could also happen if you got your username and password right, but mistyped the DSN and happened to get another valid one that doesn't accept your info.
Also, if your member login (which is also your default MySQL username) is too long for MySQL, our system truncates it automatically, and you must use that instead. You can verify the correct username information by visiting the "mysql" tab and clicking on the name of the process (ending in ".db"), which is listed under the "DSN" column. Your MySQL default username is listed under "How to Access MySQL."
Error code #2002
This indicates that the MySQL process didn't answer. In other words, it didn't even get as far as checking if your username and password were valid. This usually indicates a typo in the DSN, or that the MySQL process is not running. In rare cases, it may mean that the process is hung or deadlocked.
In some rare cases, if your MySQL process has existed for a long time without any updates to your password, it may be storing your password in a format phpMyAdmin can't authenticate against. (phpMyAdmin uses very recent PHP versions and extensions that are not compatible with archaic setups.) This will cause you to be unable to log in via phpMyAdmin, even with the correct username and password. In these cases, it is usually sufficient to change your MySQL password by another means (e.g. the command line), even if you "change" the password to the same thing.
You receive this message if you attempt to connect to MySQL without telling our system which actual MySQL process you wish to connect to.
When you created the MySQL process, you selected a DSN (also called its hostname), which is the name you must use to access your process. This name is of the form something.db and is also identified in your MySQL setup email and on your MySQL panel.
Most software packages that use MySQL offer a configuration variable of some kind to specify the DSN. You must enter the something.db name for this purpose. You cannot use localhost or leave it blank, or your program will not work, and you'll get this error message.
When setting up your site's MySQL connection information, it's tempting to skip the step of creating an additional user and just use the "admin" username (your member login name) and password. Never do that!
The first and most important reason not to do this is security. Storing your MySQL administrator password in plain text as part of your publicly-accessible web site is a really bad idea. The slightest vulnerability in your application, the web server software, or the operating system could result in a complete takeover of your MySQL process, rendering it unrecoverable to you.
Your web site doesn't need administrator privileges against your database. It needs some subset of that, and creating a dedicated MySQL user for your site with only the necessary privileges is a good way to limit exposure to SQL injection attacks and other security issues.
Second, your admin username has the SUPER privilege. MySQL only allows a certain number of connections at a time. If it runs out, either due to a problem with your application or a glitch in the MySQL process itself, your site will start getting "too many connections" errors. However, in order to make sure you can get in and fix it, MySQL always holds a single connection aside for a user with the SUPER privilege. If your site is using your admin username, you'll be unable to resolve the issue yourself because that "rescue" connection will already have been wasted by the site. If you find yourself in that situation, you'll have to open a support issue and ask us to manually restart the process.
Note: If you have a subscription membership, you can request that we log in and manually restart your process. The protective measures described above are designed to ensure that it is never necessary. If you bypass all the protections, you can still wind up in this situation.
So remember, using your MySQL admin username from your site is a terrible idea. It seems easy and harmless up front, but sooner or later you will wind up regretting it.
The MySQL "user" table that controls who can access your MySQL process contains a "Host" field that controls what hosts can connect as that user. No matter how you create MySQL users, when using our service, you should always make sure the "Host" field contains only the % character.
Since we use a clustered network with specialized nodes for hosting and specialized nodes for MySQL, you will never connect to your MySQL process from the server it's actually running on. Since things move around, you won't even know in advance which server will originate the connection. Using the % character allows connections from any of the servers on our network, which is the only way you will be able to connect. Using "localhost" or any other value will lead to connection problems.
Ordinarily, we prohibit unattended access to our systems. However, there's an exception for backups, and this definitely qualifies.
There are basically three parts:
Something on your local computer to schedule/run the backups. On a Unix system or Mac, this would be "cron." Windows has a way to do the same thing, but we are not familiar with it. So you set this up to run a task every time you want the backup to happen. (E.g. once a week.)
This command spews the backup directly to standard output, so you generally want to send it somewhere after that. If you happened to be using a Unix machine on your side and the OpenSSH client, you could do something like:
That would create a compressed SQL file on your system containing a full backup of your MySQL process on our system. To do this in an unattended way, you would need an ssh public key installed on our system that has no passphrase on the private key on your local machine.
Since the MySQL password you're using will be in the above command, we recommend creating a separate MySQL user with the minimum privileges necessary (i.e. SELECT) to do backups. You could do that from phpMyAdmin or with SQL similar to:
MySQL> CREATE USER backup IDENTIFIED BY 'correct-horse-battery-staple'; MySQL> GRANT SELECT ON *.* TO backup;
Then use backup and correct-horse-battery-staple (being sure to use a fresh random password and not this thoroughly-popularized example) in lieu of your normal MySQL username and password in the mysqldump commands above.
This will take some (or a lot of) tweaking depending on what you've got on your end, but that's the gist of how it can work.
InnoDB is a standard part of all MariaDB 10.x processes.
InnoDB can be added to older processes (i.e. MariaDB 5.3) that do not already have it. To do so, enable it from the Actions box on the MySQL info panel for that process. (A small additional fee applies.)
InnoDB cannot be completely removed. If you do not want to use it and you have a MariaDB 10.x process, you can attempt to disable it to save money by using a custom configuration similar to:
default-storage-engine = MyISAM
innodb = OFF
This setting may cause your process to use less memory (and therefore cost less), but please make very, very sure you don't have any important data in InnoDB tables before disabling it.
We do strongly recommend using InnoDB whenever possible. We use it ourselves, exclusively. The power and reliability of InnoDB are well worth the small additional cost.
To remove your MySQL process, visit the MySQL panel, click on the name of the relevant MySQL process, and select the "Permanently Remove Process" action from the MySQL Process Information panel.
When you created your MySQL process, a temporary password was set up automatically. The name of your process, your admin username, and the temporary password were all sent to you via email at that time. The temporary password is not stored and no one at NearlyFreeSpeech.NET knows what it is. Also, we recommend that you change the admin password and create additional users for your application.
Your MySQL admin username is typically the same as your member login. However, we allow longer usernames than MySQL supports, so if your username is very long, it may be truncated for MySQL. To check your MySQL admin username, view the MySQL Process Information panel in our member interface for your MySQL process. The username will be shown on the "Default Admin Username" line of the "How to Access MySQL" box.
There is no in-place upgrade between MariaDB major versions; it is too risky and too irreversible. To upgrade, create a new process and migrate your data from the old process to the new process. This approach removes the risk of an upgrade failure, and ensures you can "roll back" if the upgrade fails.
Follow these steps:
Create a new MySQL process from the MySQL tab of our member interface.
Create the necessary MySQL users to support your applications on your new process using its admin user. (What a great time to change/upgrade those passwords!)
Backup the relevant database(s) containing your data. Do not back up the mysql database or any synthetic databases like information_schema or performance_schema.
Restore the backups to the new process, using its admin login and password.
Update your application(s) to use the right DSN and password for the new process. (Save the old values in case you need to roll back.)
Test and confirm that absolutely everything you care about is working.
Disable auto-restart on the old process.
Stop the old process.
Test and confirm that absolutely everything you care about is working again.
Wait a week just in case. (Optional, but highly recommended.)
Delete the old process once you're adequately convinced the upgrade is a success.
The recommended way to backup and restore MySQL data is to use the ssh command line, but it can also be done via phpMyAdmin if you prefer.
To do step 3 from the command line, first complete steps 1 and 2, then make the backup with a command like this for MariaDB 10.x or newer:
In either case, the command is all one line, starting with mariadb-dump. Replace exampleuser with your MySQL administrator username. Replace exampleold.db with the name of your original MySQL process. Replace exampledb1 through exampledb3 with the names of all of your relevant databases in the process, as described in step 3 above.
Running this command will prompt you for the password. On success, it will produce no other output.
For step 4, load the backed-up data into the new process with a command like this:
YourPrompt$ mysql --user=exampleuser --host=examplenew.db -p <migrate.sql
Replace exampleuser with your MySQL administrator username for the new process. Replace examplenew.db with the name of the new process you created in step 1.
This command will also prompt you for the password when you run it, and should produce no other output.
When a MySQL process is first created (or started) it can be very resource intensive. After things settle down, our system can very carefully start to prune away at bits that aren't being used to get the resource usage down. This process is very conservative so as not to impact performance, and it can take a couple of weeks.
The effect of this is that the initial billing estimates of MySQL are based on a usage level that isn't (usually) sustained, so it's not unusual for it to report that a new process may cost several dollars a month because based on that limited sample, it would. But as things settle down, the estimate will typically go down to reflect your real usage. As of September 2016, the median cost for MariaDB 10 processes is about $0.60 for resources and storage combined and over 72% of MariaDB 10 processes cost less than $1.00/month.
If your usage records and estimates remain high for more than a week or two, you may wish to review your usage to see if something is more intensive than you expected. Missing indexes, for example, can really increase the resource usage of a MySQL process.
This indicates that you have altered or removed the contents of the "mysql" database of your MySQL process in a way that will prevent your process restarting, or render it unusable after restarting. MySQL processes don't restart very often, so it could be weeks or months before the effects of these actions surface, by which time you will probably have forgotten all about them.
If you catch the problem before your process restarts, you should still be able to connect to it and make a backup of your data.
If you don't catch the problem in time, there is essentially no way to repair it; your MySQL process either won't start anymore or will start but won't be accessible. You'll end up having to delete the process and start over with a new one. If you contact us before you delete the old MySQL process, we may be able to recover some or all of your data and restore it to the new one, but if this is possible and you wish it done, a non-trivial service fee will apply to cover MySQL administrator time.
Keep in mind that while our system does check periodically for this type of damage, it doesn't detect all cases and may not pick it up right away. To keep your MySQL process safe and happy, make sure you always leave the "mysql" database alone.
The "FLUSH PRIVILEGES" SQL command will also cause a running process to immediately fail if it has this type of damage.
For MariaDB 10.x and later, set the following variables in a MySQL admin session, typically either via phpMyAdmin or from the MySQL command line client:
SET GLOBAL log_output = 'TABLE'; (to make sure logs go where you can see them)
SET GLOBAL general_log = 'ON'; (to enable the general log)
SET GLOBAL slow_query_log = 'ON'; (to enable the slow query log)
You can enable either or both of the log files, depending on your needs.
After taking these steps, log contents will be in the mysql.general_log and mysql.slow_log tables; no restart is required. Please see the MariaDB documentation for full details.
When you are finished, make sure to disable logging again, and truncate the log files to save space and cost:
SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';
TRUNCATE TABLE mysql.general_log;
TRUNCATE TABLE mysql.slow_log;
For MariaDB 5.x, logging to tables is not supported. If you have an older process, consider upgrading, but in the mean time:
We are happy to receive reports about problems, no matter the source. However, if you report a technical problem with someone else's services, you may get a frustrating response.
Our Privacy Policy doesn't allow us to discuss our members' services with other people without the affected member's consent. That includes problems and our efforts to fix them or alert the affected member. Therefore, we can respond to problem reports from the public only by acknowledging the problem so you know we received your report. Unless the problem is specific to you, we will not provide any additional information.
Sometimes, people interpret our inability to discuss the problem as blowing them off or a sign that we're not going to do anything about it. This is not the case at all; it is merely an artifact of properly enforcing our Privacy Policy.
What does discussing problems have to do with our Privacy Policy? Although the simple answer is that our members' services are nobody's business but theirs until they tell us otherwise, the practical reason for this is a little more complicated.
From time to time, we get reports like, "I went to www.example.com and it was down! Fix it! You people suck! Your servers suck!" While we can generally say "Yes, the site is down," we do not go into why or when it might be back in response to such a report, which sometimes means the person goes away believing that not only do we suck, but we suck on purpose!
There are many reasons a website might be offline. Maybe the person couldn't pay. Would you want us to discuss your billing status with anybody who asks if it was your site? Probably not. But if we respond to all "site down" complaints but only stonewall the ones where billing is involved, stonewalling becomes a substitute for saying that it's a billing problem. So, to protect our members' privacy, we must treat everything as a private matter even if it makes us look like we're unwilling or unable to fix a problem.
(Those who are paying attention may have noticed the similarity to the old philosophical problem of encryption: if you only encrypt things when you have something to hide, using encryption is a clear sign that you have something to hide. For encryption to be maximally effective, you have to encrypt as much as possible. Others may have had similar experiences trying to find out the condition of their hospitalized friend.)
So, if you are a member of the general public, please do not assume the worst of us because we won't discuss a problem you found. We ask that you remember that our Privacy Policy is a promise to protect our members all the time, not just when it's convenient for you or when it makes us look good. Your patience and understanding will be appreciated.
Of course, if you're having a problem with your NearlyFreeSpeech.NET services, you can always expect full disclosure regarding any issues and our full support in helping to resolve the problem.
Please feel free to report downed sites or other technical problems with NearlyFreeSpeech.NET services to support@NearlyFreeSpeech.NET even if you are not a NearlyFreeSpeech.NET member (or if you are, but not the owner of the services in question). We want to make sure our members' services stay working at all times, and we'll take any tip we can get when something might be amiss.
If you are a member and there's a problem with your services, contact us through our site if at all possible so we can get started right away and not have to goof around making sure it's you.
Our strict privacy policy absolutely forbids us from providing information, including contact information, about the operators of services we host in response to public inquiry. We take our commitment to our members' privacy very seriously.
Therefore, you should attempt to contact the operator directly.
In many cases, the operator has contact information on their website. That's the best way to reach them. If such information is not available, but the site has a registered domain (i.e., the site name does not end in "nfshost.com"), you may wish to consult the public whois information for the domain, which is generally required to include accurate contact information.
If the operator chooses not to include contact information on their site and is not using a registered domain, you may safely conclude that they do not wish to be contacted.
Please do not send us messages for members of our service, as we will not forward them; we do not have the resources to act as a go-between messaging service between site operators and people who wish to contact them, nor is it our place to second-guess their decision about how they prefer to be contacted.
We encounter a variety of situations where people contact us claiming to be the rightful owner of a web site or domain managed through our service. Such claims are typically accompanied by demands to allow the person to take over, transfer services, or take something down.
Our policies are extremely strict and are designed to provide maximum security to our members. At NearlyFreeSpeech.NET, memberships are held by individuals. The individual person we have on record as the holder of a membership is the only person authorized to access that membership or direct us to take any action related to services we provide under that membership
This puts people wanting access to a membership into two categories:
First, the person whose name is on the membership. Occasionally, a member will mislay their login credentials and be unable to access the system. We are able and happy to assist with a variety of such matters; they have their own FAQ entry with the specifics.
Second, everyone else. This includes customers, vendors, employees, employers, contractors, co-workers, relatives, friends of members, and current or former members with adjunct access, not just the general public. We apologize, but we are not able to assist you under any circumstances, unless expressly authorized to do so in advance by the relevant member, and even then only under a very limited set of circumstances (such as allowing a predesignated party to make deposits or renew domains in case of emergency). Any concern or conflict you have with the member hosting the services with us, including problems contacting them, must be resolved directly with that member or via channels other than us (e.g. the court system). There are absolutely no exceptions.
We apologize to anyone negatively affected by our hardline stance on protecting the privacy and security of our members. While this often seems harsh to people already having some other major problem not caused by this policy, we ask them to please keep in mind the absolute chaos that would result if we handed over web sites and domains to anyone who asked for them via email based on their say-so. Thank you for your understanding.
Note: If you contact us about accessing hosted services on a membership and you receive a link to this FAQ entry in response, then it is applicable to your inquiry, and that is the end of the discussion.
This is the case even if you believe (or wish) otherwise. It is not unusual for people who receive such a link to think that they or their circumstances are special and therefore this entry does not apply to them. That is not the case.
If you want to obtain services hosted by a member of our service, and you are not that member, then you have several options:
Obtaining the member's assistance is always the first and best choice.
If you know who the member is, sue him or her in a court of competent jurisdiction, win, and obtain a court order requiring the transfer of the assets of interest to you.
If you do not know who the member is, file an in rem lawsuit against the content itself in a court of competent jurisdiction, make sure we are notified of the proceedings so we can attempt to notify the member, win, and obtain a court order requiring the transfer of the relevant assets to you.
Absent the above, contacting us asking for access to someone else's stuff is a complete waste of your time.
The simple answer is that we allow offensive content — whether that means offensive to you or offensive to us — because our Terms and Conditions of Service allow all legal content and it's not illegal to be offensive.
The real question, then, is: why we don't we change our Terms and Conditions of Service?
Well, everything from this FAQ entry and our Abuse page definitely applies. But when you get into websites that advocate or represent viewpoints that are particularly offensive and harmful, there are additional reasons.
Most importantly, websites that advocate or represent viewpoints are created by people who hold those views. If those people are willing to stand up and wave their hands and say "Hey! Here I am! Over here! Look at me!" we prefer to let them. To some extent, we are willing to host certain types of content to rub the world's nose in the fact that people who think that way still exist. And if that makes you uncomfortable, good, it's working.
In addition to that, we have very strict requirements to provide accurate contact information and we operate from a nation of laws. If someone who hosts a site on our service engages in criminal activity and the police come to us for help (with appropriate warrants/subpoenas/etc), we're very likely to be able to provide not only information, but technical assistance that may be essential to catching them. If we kick them off and they pop up twenty minutes later on some third-world ISP that hasn't put our level of thought into their policies, doesn't keep good records, and doesn't have the legal system we enjoy, that opportunity is lost.
Of course, the simplest reason is that it's not up to us to decide what the rest of the world should or shouldn't see. Bad news, it's not up to you either. Worse news, it's still true even when we agree. Which is probably most of the time.
Finally, censorship is always bad, for a variety of well understood reasons that we don't need to repeat here. But in the case of some types of content, it has special dangers. When you censor a web site based on the extreme or dangerous views of its creator(s), you haven't stopped those people from thinking that way. You haven't made them go away. You certainly haven't stopped the people who hold those views from doing whatever else they do when they're not posting on the Internet. What you've actually done is given yourself a false sense of accomplishment by closing your eyes, clapping your hands over your ears, and yelling "Lalala! I can't hear you!" at the top of your voice. Pretending a problem doesn't exist is not only not a solution, it makes real solutions harder to reach.
So that's why we host really, really offensive content. It's not because we like it. It's certainly not because we agree with it. And it's not because we profit from it; our MFFAM policy makes sure of that.
It's because we've spent a long time thinking about this very carefully and concluded that it's the best course of action. But that's our opinion. We respect your right to hold — and to express — a different view.
Please note: If you found this because of a specific site that falls into the offensive-but-legal category that you were hoping to censor, here is what you should do instead:
Speak out against the views espoused on that site.
Learn more about the issue so that you can advocate effectively against it.
Find a way to become locally involved in activism related to the issue.
Donate money to related causes.
That's what we do. Unfortunately, all of those things do take more effort than demanding censorship. But they're both useful and effective, whereas censorship is neither. If you're upset by something you see online but not upset enough to do these sorts of things, then "don't look at it" is probably the best advice we can offer.
This process works a little differently here than it does with most other services. At NearlyFreeSpeech.NET, responsibility is divided into two distinct pieces: a membership and an account.
A membership represents an individual person. A person can only have one membership, which has their real/legal name on it. Memberships cannot be shared or transferred.
The account is a separate piece under the membership that contains money, sites, domains, everything related to hosting for a specific entity (which might be the same person, or it might be a company, club, or organization.).
So, in order to take over responsibility for hosted services, following process:
Make sure our service is a good fit for you. If it isn't, it's best to find that out beforehand.
Create your own membership in your own name. If the other person tries to give you their username and password, don't let them! Never access a membership created by someone else.
Establish with the other person exactly what you are taking over. This could range from a whole account full of services down to a single site or domain name. The important thing is that you both agree on exactly what is to be transferred.
If you are receiving anything other than a full account, you must create an account of your own and fund it.
When you are ready, both you and the other person should submit identical "transfer" assistance requests in our user interface. (More detailed instructions are available in our Member FAQ.)
Requests to manage hosted services or renew domains will not be honored unless they have been properly verified according to the authentication methods previously established by the membership owner. Generally, this means that the individual member logs in to our system to take the appropriate action. However, there is one exception to this policy.
Transfers between member accounts that consist only of funds may be made with only the approval of the sending member. In other words, anyone with a funded NearlyFreeSpeech.NET membership can transfer funds to any other member's account if (and only if) they know the recipient's account number.
This means that the following conditions (and only these conditions) can be resolved by anyone:
A site hosted here is unavailable and the only reason it is unavailable is a lack of funds.
A registered domain that meets all of the following criteria.
The domain is currently registered through us.
The domain is currently within the auto-renew period (from about ten days before expiration to about 30 days after expiration).
The domain was previously set to auto-renew by the member.
The only reason the domain has not auto-renewed is the lack of funds.
Please note that our system does send out-of-funds and domain auto-renewal failure notifications to the member's contact email address but that our privacy policy strictly prohibits us from discussing or disclosing information about the applicability of these conditions to any particular situation in the absence of a properly-verified request from the member. In other words, we cannot tell you whether or not the unavailability of services obtained through us results from a lack of funds.
If you believe you are in this situation, you can take the following steps:
Create a new NearlyFreeSpeech.NET membership.
Make a payment sufficient to cover the expected costs.
Use the "Transfer Funds Between Accounts" action on the Accounts tab.
Enter the recipient member's account number as the Destination Account.
Select the "To another member's account" transfer type.
Enter a transfer amount sufficient to cover the expected costs.
Select the "Transfer Funds" button.
Please keep in mind that although hosted services typically come back online within a few minutes if lack of funds was the problem, domain registrations can take 24-48 hours to start working again if they were expired at the time of renewal.
If you do not know the member's 12-digit account number, you will not be able to use the process above.
The following additional information applies only to individuals who cannot access their membership.
Under ordinary circumstances, our Terms & Conditions of Service impose a strict limitation of one membership per individual, for good reasons. Under ordinary circumstances, completing the appropriate recovery process to regain access to your membership is strongly preferable. We provide extensive recovery options for a lost username or password,
a lost email address, or
a lost two-factor device. But under ordinary circumstances, a member logs in to our site and does whatever they need to do, and they do not wind up reading this.
If extraordinary (but temporary) circumstances exist — like if a member is temporarily unable to log in to their regular membership because they are traveling and don't have needed info to access or recover it — where violating the letter of the one-membership-per-person policy by creating a second membership for the sole purpose of depositing funds into the first will mitigate larger harm, we allow it.
However, the "temporary" qualification of those extraordinary circumstances is significant. Taking this action is only a good idea if "temporary" applies. In other situations, taking this action may not mitigate larger harm; it may make things worse.
Although it is extremely rare and our system takes many precautions to prevent it, it is remotely possible for a member to, through a sufficiently large combination of consecutive instances of bad judgment or dishonesty, engineer a situation where they have set security protocols to verify their identity that they subsequently they have no way to meet. In such cases, it is very likely to be preferable to allow services to be deleted and then pursue recreating them once they are removed from the inaccessible membership. Adding funds through this process may only increase the delay before that happens.
Adjunct access is a sharing tool that allows you to grant another member SSH and SFTP (and, if you enable it, FTP) access to one of your sites. It also allows them to view some information about the site in our member interface. It does not allow them to modify that information.
If you need more powerful sharing that allows editing site settings, DNS, and other services, account sharing may be a better choice than adjunct membership.
To grant adjunct access to another NearlyFreeSpeech.NET member:
Select the "short name" of the site you want to share; this will take you to the Site Information panel.
Find the "Adjunct Members" box.
Use the "Add an Adjunct Member" button.
Provide the other member's login name on the "Add Adjunct Member" panel.
Confirm with the "Add Member as Adjunct" button.
If you have more than one site, granting a member adjunct access to one site will not enable them to edit any of your other sites.
When the other member does not have a funded account, adding the member to your site confers "Adjunct" status on that member. The member you add must already exist with a confirmed membership.
Adjunct members are not required to pay anything, and their memberships will not expire for non-payment as long as they have adjunct access to at least one site. Of course, they are still entitled to fund an account and create their own sites at any time without restricting their ability to share one or more sites with you.
There is no additional security within a site; any member who has permission to access the site can access or modify any part of the site content. Adjunct access grants full control over the content of your site but not the administration of it. Therefore, they may change or delete all the content on your site, but they cannot remove it from our system, close your accounts, see your balances, or perform any other activity unrelated to site content.
You are solely responsible for providing any support needed by members who do not have an account and a subscription membership with us.
All members must go through the signup process themselves to create their own memberships and agree to our Terms & Conditions of Service; you may not create NearlyFreeSpeech.NET memberships for other people.
We offer a "give us your two cents' worth" free trial to new members. This trial allows people to use many of our services for about a month to help figure out if our service is right for them without the need to make a deposit. However, we have been forced to apply certain limitations and restrictions. Here they are:
NearlyFreeSpeech.NET is not free. The purpose of the "two cents" trial is to help you evaluate our service; it is not for production usage.
Unless you make a deposit, the free trial will eventually expire even if it isn't used. It lasts about a month.
Some system features that are expensive or abuse-prone may be restricted or prohibited on free trial memberships. (Examples include domain registration, email forwarding and sending emails from hosted sites.)
We intend to allow no more than one free trial per person per year, and we may take steps to block or remove people who sign up for multiple free trials to avoid paying for our service.
If we detect abusive or disallowed behavior during the free trial, we will summarily disable or remove the trial membership without warning.
The perks of subscription membership (including individual private support) are not available during the free trial.
We are happy to provide member support to free trial members through our free support options, such as our forum. However, if a question indicates usage not consistent with the intent of the trial offer, we may not be able to assist.
A resource accounting unit (RAU) is a basic unit of web site resource utilization on our network. It is currently defined as a memory usage integral totaling use of one gigabyte of memory for one minute, or the equivalent amount of CPU if a system is CPU constrained.
To provide a simplified example, suppose a single site is running on a dedicated server with 4 gigs of RAM. That server is "worth" 4 RAUs per minute. But if the site is only using half that server's resources (whether RAM or CPU -- whichever is greater since the server is "full" no matter which one runs out first) over a minute, then it would accrue only 2 RAUs during that minute. If the site becomes idle the next minute and has no requests, it accrues no RAUs during that minute.
RAUs are currently used in conjunction with server types that feature resource billing. If you are not using such a server type, RAUs used by your site are ignored and will not be billed. They are still calculated and presented for your information and for our use in capacity planning.
If your site aliases are flagged with the 🔁 emoji then their TLS is managed automatically by us and you do not need to do anything.
All sites created after 2024-05-22 have TLS managed automatically. Older sites that previously used tls-setup.sh have been migrated to automatic TLS management. Using tls-setup.sh to set up new TLS on existing sites is not supported.
If you have an older site that does not have TLS and you now wish to enable automatic TLS:
Go to the Site Information panel for your site in our member interface.
In the Actions box in the upper right, select the "Enable Automatic TLS" action.
Our system will start attempting to generate and install TLS certificates within a few minutes (subject to load).
Each account can have an optional alternate emergency contact, which is the email address of someone who you are authorizing to take certain very specific actions related to that account if you are unavailable:
If something is down or disabled and they inquire, we may explain what the problem is and what they may be able to do about it, if anything.
We will help them deposit funds into the account if it is empty or nearly empty. (Nearly empty = below the lowest account balance warning.)
We will allow them to authorize the renewal of expired or nearly expired domains on that account using funds on that account. (Nearly expired = set to "manual renewal" and generating renewal warnings.)
We may allow them to take or authorize other actions necessary to preserve the account or the operability of the services it funds. In cases like this, if we think something fits the spirit of the alternate emergency contact, we will ask both them and you if it should be done, and it will only be allowed if they say yes and you don't respond within a reasonable time depending on the urgency of the situation -- defaulting to 24 hours.
These are the only circumstances where the alternate emergency contact can be used. Alternate emergency contacts cannot: close accounts or request refunds, request inbound or outbound domain transfers, or delete anything. The emergency contact role is limited to preserving what's already there. Even so, human factors and judgment are involved, so you should not make someone an emergency contact unless you trust them and their judgment; you will ultimately be responsible for whatever they do, because you authorized them to do it.
This feature is intended to allow a level of resilience in the case of accounts held on behalf of businesses or customers where the member responsible for the account might go on vacation or otherwise be unavailable when something goes awry. It does not change the ultimate responsibility for the account and its assets at all; specifically, the alternate emergency contact does not create any sort of shared or simultaneous control of the account.
The emergency contact need not be a NearlyFreeSpeech.NET member already, though we may ask them to create a membership if necessary to perform a certain function, like making a deposit.
Do not enter your own email address as the emergency contact. The emergency contact is the person we contact when you are unreachable. Telling us to contact you when you are unreachable serves no purpose.
Storage is billed in terms of megabyte-days. A megabyte-day represents the use of one megabyte of space for a one day period. This means using 31 megabytes for one day is the same as using one megabyte for 31 days. The "Unbilled Storage" numbers displayed on the Account, Site, and MySQL panels are in byte-days. 31 megabyte-days is equal to 32,505,856 byte-days.
The amount of space that your sites and MySQL processes use is measured periodically based on the number of disk blocks they utilize. These blocks are the system default block size, and represent the smallest possible allocation of disk space; even very small files and empty directories require at least one block each. The system then takes the average of that measurement and the prior measurement. The number of megabyte-days is then calculated on a pro-rata basis using the interval between the two measurements.
No. Currently you are not charged for ssh bandwidth usage. That's subject to change at some point, but it would hardly matter as it would take you a very long time indeed to pass a gigabyte of data doing the sort of activities we allow via ssh. For example, if you are editing a web page on an 80x25 terminal, you would have to redraw the entire screen over 530,000 times to get to a gigabyte of traffic.
Because this traffic is negligible, we've never bothered. Of course, if this feature were to start getting abused, we would have to reconsider, but fortunately our members have been very conscientious about their ssh usage.
Each site has a home directory that lives somewhere on our network, called the site root. Inside the site root, there are several subdirectories:
conf
This directory can be used for configuration files that shouldn't be in the public web directory. It can be used to customize PHP or to store configuration files for custom web servers and other daemon processes.
logs
This directory is used for your access and error logs (both current and archived) if you choose to enable them.
private
This directory is yours to use for files that you do not want accessible via the web at all. For example, if you're compiling a custom C++ or Go application, putting the source code in this directory would be appropriate. This directory is also your "home" directory for Unix shell purposes.
protected
Files in protected are accessible to scripts and daemons but cannot be directly downloaded over the web. For PHP and CGI applications, this should include libraries, frameworks, config files, data, or other support files that the scripts in the public folder need to operate. For daemon processes, everything but static content typically goes inside protected.
public
This directory is the heart of your site. All of the content in this directory is directly accessible via the web. Put all your static HTML files, images, .htaccess files, and directly-accessed PHP or CGI scripts in this directory and, to the best of your ability, absolutely nothing else.
tmp
This directory is for transient (temporary) files, like files uploaded via PHP before they get processed, or for session-handling files.
Old sites may also have a symbolic link from htdocs to public. htdocs is a historical name for the same directory. It is not used by our system.
Resource billing plans charge you based on the amount of resources (currently CPU and RAM) that your site uses. There are two types of resource-based billing: individual and stochastic. For both types, your site will be assessed a charge based on the resource accounting units it accrues.
Most newer sites types (mainly PHP 5.4 and later) support individual resource billing. For these, our system keeps track of the amount of CPU and RAM used by that individual site and generates accounting records based on that usage.
If you have an older site that is not using a resource-billing server type (aka "legacy billing"), its resource usage may still be measured for our internal use in load balancing, so you may see resource usage information in the control panel, but you will not be charged for it. Your storage costs, however, will be considerably higher.
Memberships represent an individual person and as such are non-transferable. Therefore, any kind of transfer will require the recipient to have a membership of their own. Once that is accomplished, there are a couple of different ways to proceed.
Option 1: You can transfer an account in its entirety, which will also transfer all sites, domains, and MySQL server processes funded by that account, using the Transfer an account between memberships assistance request.
Option 2: If the recipient already has an account, you can transfer items such as sites and domains individually from your account to the recipient's account using the Transfer assets between accounts assistance request.
You'll need to make sure you account for the migration of any MySQL data that might be living on a MySQL process you own, but do not wish to transfer to the other member; a site that depends on MySQL will break if it is separated from its database(s). Similarly, if you transfer a site that uses one or more domain names, it is generally necessary to transfer the domain name(s) as well.
In accordance with our policies, the balance of any account transferred between two parties becomes nonrefundable. Also, since we do not allow you to have more than one membership, we will generally not help you transfer assets between memberships if we determine that you control both memberships, unless one of the memberships is being closed as part of the transfer.
Two-factor authentication is a very important method of protecting your membership. We use the OATH method, which is widely supported by two-factor apps, like Google Authenticator and 1Password.
The list of steps below looks formidable, but they're all bite-sized and you'll be through them in no time. There's also plenty of information available along the way; this is more of an overview of what to expect and guidance for how to get the best results.
In the "Details" box, on the "Two-Factor Security" line, select the "Setup" button.
Get your 2FA app ready to capture a QR code.
On the "Two-Factor Setup" panel, press "Continue."
Scan the QR code with your 2FA app.
Confirm that your app is showing a 6-digit code.
Select "Continue" in our interface.
Enter your password and two consecutive codes from your 2FA device.
Carefully read the warnings.
Check the box indicating that you understand the warnings.
Select the "Activate Two-Factor Security" button.
Select the "Generate Recovery Codes" button.
Select the "Update Recovery Codes" button.
Write down, save, or print the recovery codes and keep them in a very safe place (e.g. stored with strong encryption or kept in a physical safe).
Select the "View Recovery Settings" button.
Review and edit your recovery settings on the "Manage Recovery Settings" panel to make sure they properly balance security and convenience for your individual needs.
Going through this whole process should take about five minutes, and will help keep your membership secure for years to come.
No. The IP addresses listed for your site in your member control panel may change as part of how our load-balancing system works (although that doesn't happen often) or if a site using a particular IP address suffers certain types of attacks. If this is of concern to you because you are configuring third-party DNS, please see this FAQ entry for instructions.
If you or someone else has cached or is otherwise using an IP address that is no longer listed (perhaps due to not following the instructions above), it is generally not a problem. At any time, any of our dozens of member site IP addresses will provide your site, whether they are listed or not. We will announce if we ever permanently remove any IP addresses from this pool.
We are very sorry to hear that, but we understand that we are not the right environment for everyone. Just select the "Cancel Membership" action on the Profile tab in our member interface to let us know to close your membership and (if applicable) return the remaining balance in your account(s). We'll take care of it. (You must request the closure via this mechanism; to protect your privacy and security, you cannot close your membership via email.)
We will return your remaining funds by the same means you used to deposit them unless that is not possible (e.g. a closed PayPal account or cancelled credit card, or a credit card payment made more than a few months ago). Otherwise, we will offer you the best available options which include sending a check (less a small fee) if you are a US resident, transferring the funds to another member, or donating them to a deserving site or the EFF.
We have a no-hassle cancel policy, so you aren't required to provide a reason for cancelling, but we hope you do. We really appreciate feedback from all our current, former, and future members because that is the only way our service improves. However, if you think there's something we could help you work out to get you to stay, please let us know before you submit a cancellation request. Specifically, please don't use the "reason for cancelling box" to say anything like "if you do XYZ I won't cancel." By the time we respond, some or all of your cancellation may already have been processed. That's a missed opportunity to put things back on the right track, and we hate to see that.
Important: If you have any domains registered through us, you musttransfer them to another registrar or
wait for them to expire and be deleted before you will be able to cancel your membership. This is ICANN's policy, not ours.
You should only ever have one active membership (because the membership represents "you" as an individual). Creating or accessing multiple memberships is a violation of our Terms and Conditions of Service. Doing so will cause all sorts of problems and may result in substantial additional fees (up to $50.00 per incident*) if we have to step in. If you've already done this accidentally, and for some reason, we haven't detected it, please send us Transfer assistance requests from both memberships to consolidate your accounts onto one membership.
Your membership may have multiple accounts if you wish. Each account represents "a discrete pool of money." That's optional; you need at least one account to use our service, but we never require you to have more than one.
The ability to create additional accounts has no technical effects on your hosting. Provided an account balance is positive, you may create and manage as many assets (websites, domains, databases, etc.) as you like funded by that account.
It is solely a convenience feature that allows you to differentiate ownership of funds and assets, help track/control your spending, and share things when multiple people are involved in a project.
Often, this is done for tax, business, or legal purposes, such as:
Separating business and personal services
Segregating expenses if you need to manage services for clients, organizations, etc.
Tracking how much the assets for a specific project cost
Multiple accounts can also be useful if you have one site that is very active or given to surges and another that must always remain available. If both sites are on the same account and the account runs out of funds, both sites will be disabled. If they are on separate accounts, the busy site can never cause the other site to become disabled.
Therefore, you never have to create a second account for yourself to host an additional site, but you do have that option if it suits your needs.
For more information about setting up services that will be shared with others, see this related FAQ entry.
*Look, we don't like charging this fee. It makes us sad and we actively try to avoid it. If you keep violating our policies after a warning, we'll be sad, and you'll be out $50.00. (Possibly more than once, if you persist.)
Our service is fully paid in advance; charges (and services) automatically suspend when your account runs out of funds. Under ordinary circumstances, it is not possible to overdraw your account. Here are the least uncommon extraordinary circumstances:
If your usage is just right when your account is depleted, you can wind up with a negative balance of a penny or two. If that happens and you don't want to add additional funds, don't worry. When you cancel, our system will discard the overdrawn amount.
If you are being charged per day for RespectMyPrivacy service, it can overdraw your account. Usually, RespectMyPrivacy is charged per year, but there are two exceptions:
If you have had a registered domain with RespectMyPrivacy service since per-day billing was the norm and you have continuously maintained a low account balance.
If you request RespectMyPrivacy for an inbound transfer of a domain registered for multiple years, and you don't have enough funds to pay for the privacy charges once the transfer completes, it will auto-switch to daily billing.
In either case, the unpaid privacy service can overdraw your account. That is intentional; the consequences of disabling or canceling that service are permanent. Once your information becomes public, reactivating privacy later won't cause people to unsee it or remove it from databases that track whois changes. We would rather lose money than let a brief lapse permanently compromise your privacy.
So, because we do respect your privacy and we know that oversights happen, we won't cancel RespectMyPrivacy service for lack of funds. However, when you hit zero, we will apply the associated charge as a negative balance that you will have to clear before accessing any services. If you leave a balance negative due to unpaid privacy charges for more than 30 days, affected domains may be suspended for having invalid contact information.
The best way to check this is to go to the Account Information panel for the overdrawn account and look at the "Estimated Recurring Activity" box. It will contain a "RespectMyPrivacy Service" line showing how many domains you have with privacy service and how many are prepaid.
Chargebacks can also result in a significant negative balance. You must resolve any chargebacks and related negative balances before you can cancel your membership or access any services paid for by the charged-back funds. ICANN allows chargebacks as one of the few justifications for a registrar to suspend or seize a domain name. We dispute all chargebacks as a matter of policy and take a dim view of people who file them. (Except in cases of credit card fraud, where we take a very dim view of the person using a stolen credit card with our service instead.)
Vanishingly few members will ever see a negative balance. If you do, we hope you will correct it as soon as possible to ensure the successful operation of our services.
Here is a summary of what can and cannot be changed:
Memberships
NearlyFreeSpeech.NET memberships are held by individuals, must not be shared or transferred, and must use your real/legal name.
Your legal name is the one on the government-issued photo ID you would show us to regain access if you ever got locked out. There are some cases, e.g., transitioning individuals, where your real name may be different. In those cases, we ask for both so we can address you properly for everyday tasks but still match your ID if needed.
If you have legally changed your name (for any reason), you can submit an assistance request to have us update it in the system for you.
If you were interested in changing the name because you want to transfer control of your hosted services to someone else, stop and see this FAQ entry instead. If you're interested in changing the name because someone gave you the login name and password to a membership with their name on it, stop accessing our system immediately! Contact them, and tell them to transfer things to you properly.
You can request a change to your login name at any time for a nominal fee (waived for subscription members) through the same assistance request. No reason is required.
Sites
You can add and remove aliases from a site at any time through our member interface.
The short name of a site cannot be changed without creating a new site, moving the content over, then deleting the old one.
Accounts
The account name can be changed at any time from the Account Information Panel in our member interface.
The account number (e.g., A1B2-C3D4E5F6) cannot be changed.
MySQL Processes
MySQL process names (DSN's) cannot be changed. You must create a new one, move any needed content, then delete the old one.
MySQL does not provide a builtin way to rename databases, but tables can be renamed using the RENAME TABLE SQL command.
Our system allows the general public to make payments to contribute to the hosting costs of sites hosted on our service. They can use any of the supported payment methods to do so. However, to limit abuse, restrictions apply and there is an approval process for this feature. Contributions can be enabled on a per-site basis. When enabling contributions, you may elect whether or not to set a contribution code that potential contributors will be required to enter. (Use of this code is recommended when the pool of potential contributors is limited to a small, closed community.)
We do impose some strict limitations on you in conjunction with contributions, the largest of which is that you cannot provide anything of measurable value in exchange for contributions. (In other words, you cannot use it as a substitute for eCommerce.) Also, we will not under any circumstances refund to you as cash (or equivalent) any payments made by third parties. Finally, we are very unlikely to accept donations on behalf of members who have not yet funded an account themselves.
It is also possible to use the contribution system if you are a web professional maintaining sites on behalf of a third party who does not have the desire or ability to maintain their own membership on our system. Using the contribution system, they can make payments for the hosting services you are managing for them without having to give you their payment information and without you having to pay us and then seek reimbursement from them.
For complete information about the contribution system, or to request approval, see the relevant assistance request.
We do not recommend this. It is better to delete all your files and reuse the existing site.
If you do choose to delete a site and then create another with the same, we recommend waiting at least fifteen minutes between deleting and creating. If you don't, some parts of our system may get confused and continue to try to access the old (gone) site.
If your site has the wrong short name then you will have to delete it and create another. Short names cannot be changed.
Our Terms and Conditions of Service do not allow our service to be used to transfer money from one person to another because that would be a regulatory nightmare and fraud magnet. So if you make a payment from a PayPal account with an email address that does not match your contact address, our system automatically assumes that the deposit came from someone else and may warn you that it's nonrefundable.
In practice, this only matters if you close your membership with a remaining balance from such a payment. Even then, it is rarely an issue.
We can always attempt to refund the money to the PayPal account it came from, whether that was you or not. In rare cases, usually when the sending PayPal account has since been closed, that might not work.
If it doesn't, but you are John Example, your contact email address is john.example@gmail.com and the payment came from john@example.com or some similar situation, we'll probably be able to do the mental heavy lifting required to connect those dots and get the money back to you. But we can't guarantee that, because it's a little subjective.
If the sending PayPal account no longer exists and we can't positively correlate the original payment to you, that can result in us being unable to issue a refund. (Hence, "nonrefundable.") But even in such cases, we don't just keep the money; donations to charity or transfers to other members are still possible.
Most synthetic traffic (i.e., traffic that does not represent a real person or computer making a real request of a service we host) is dropped at the edge of our network due to our network and firewall architecture. This protects our members' services from several types of denial-of-service attacks.
If you attempt to ping something on our network (e.g., your website), you may get a response. However, this response is a fake generated by our firewall and does not necessarily indicate that your site is reachable. We do sharply limit the number of outbound ICMP ping replies we send at any given time, which can mean your ping requests won't even get fake replies if someone is ping-flooding us; attempts to ping-flood us are very common and completely ineffective, largely because of precautions like these. Therefore, an (in)ability to ping your site does not indicate that it is or isn't working properly.
Some traceroute applications, like most under Unix, use UDP packets to probe network hops. These applications frequently show a "filter prohibited" response (usually "!X" or "!N") or a routing loop at the edge of our network. Others, most notably the tracert.exe provided with Windows, use ICMP to probe network hops and may be fooled by our fake ping responses. Both results are normal and, like ping results, should not be used as the basis for a problem report.
If you need to traceroute to our network to diagnose an intermediate connection issue, you can use the hostname traceroute.nearlyfreespeech.net for this purpose.
To accurately measure your site's performance and availability, you should complete an actual HTTP request to the site, checking both that it responds correctly and how long that response takes. This would be true even if we weren't playing games with ping and traceroute because overloaded or malfunctioning servers often respond quickly to pings but slowly or not at all to real traffic. Various utilities exist that can be used to test HTTP servers, such as wget, curl, and fetch.
We're delighted to have people refer us to their friends. In fact, we absolutely depend upon it for growth because it lets us focus on building a better service. However, this situation does create a couple of occasional problems that border on heartbreaking for us, so we've created this FAQ entry to offer some guidelines. (Although there are other types of referrals than male friends, we're using the words 'friend' and 'him' here for the sake of simplicity.)
First, and most importantly, you absolutely, positively, must not ever create a membership for anyone other than yourself. Not only are memberships non-transferrable, but you have no legal authority to agree to our TACOS on behalf of a third party. Your friend needs to read, understand, and agree to our TACOS for himself. Those are the rules for using our service, and we don't want people on our system who don't know the rules. Therefore, your friend must complete the signup process for himself.
Second, please make sure that your friend is equipped to manage or maintain his site(s) without ongoing assistance from you. You are not allowed to access other people's memberships! We have gotten into several painful situations because someone "helped" their less tech-savvy friend by setting them up on our service, then disappeared for whatever reason, and the abandoned friend expected us to provide whatever assistance they were promised because no one ever explained the limited scope of support to them. We simply don't have the resources for that, and it invariably winds up with the friend hating us and blaming our "unhelpful support" for not keeping someone else's promises. Please, please, please don't put us in that position. It hurts.
Third, when telling your friend about our service, make sure your friend understands and is comfortable with the scope of our member support. People who are used to lingering on the phone while someone walks them step-by-step through their individual setup sometimes don't appreciate receiving an emailed link to our FAQ when they ask us a basic question. Remember that although you may not need that type of help, some of your friends might. For friends that do, the added cost of a service that provides the extra assistance they need is a very good investment.
What should you do to refer a friend to our service? There are four basic approaches you can choose from, depending on your needs (and those of your friend).
First, you can tell your friend about it and let him do everything himself. This is by far the easiest way to go, and is often the best if your friend is as smart and clever and inclined to do his own thing as you are. (You must be; you picked us!)
Second, you can tell your friend about it, get him to sign up, and then share a site using our adjunct access feature. With this option, he can either create an account and site of his own and make you adjunct, or you can create the site on your membership and make him adjunct. This is the best approach for people who are going to be collaborating on a site.
Third, set up your friend's site, domain, etc on your account and then have your friend create a membership of his own and, when everything is ready, transfer the whole deal to him with a couple of quick support requests. You can either create a second bandwidth account to contain the site and transfer the account between memberships, or your friend can create and fund his own account and you can transfer the relevant bits individually. This is the best approach when you're preparing the site as a gift or favor, but your friend is willing and able to maintain it over the long term.
Fourth, you can create a separate bandwidth account under your membership, use it to fund your friend's site, and manage it all yourself. With this approach, your friend never touches the site personally. This is the best approach for people reselling our service, and for use with friends who want websites of their own but still compulsively forward emails about stolen kidneys and Bill Gates paying email users. ;-)
Again, we are thrilled and grateful to receive all kinds of referrals. We're providing this information solely to help you make sure that any referrals you give work out well for everybody involved.
Visit the Profile pane and, under "Details," verify which email address is the existing one, and which is the pending one. They should both be listed.
Click "Change Email Address" from the "Actions" box.
Enter your existing email address in the "New Email Address" field. Click "Save Changes."
You should be taken to a page that says, "Your request to change email addresses has been cancelled." Click "Click here to continue." You should be returned to the Profile pane and see that your existing address is now the only one listed.
Repeat steps 2 and 3 above to change your address again to a new one, and check your email for a confirmation message. If you do not find it, please be sure to check any spam, junk or trash folders you might have on that account before contacting us for assistance.
Our handling of DMCA notices and the notification-and-takedown process is built around our commitment to treat DMCA notifications as what they are: allegations of copyright infringement, not evidence of copyright infringement. Receiving a DMCA notification does not mean you have done anything wrong.
When you signed up, you agreed to follow our TACOS, and one of the things you agreed to was not to infringe other people's copyright. When you upload content to our service, you assert that you have the right to make that material available. So, on the one hand, we have you, who we have a contract and a relationship with, promising us that your content is legitimate. On the other, we have some random person we've never met who has no relationship with us claiming that it isn't. Under those circumstances, our first inclination is to believe the person we know and trust: you. For that reason, we do not interpret receipt of a DMCA notification as prima facie evidence that you have done something wrong.
However, that's not how the DMCA takedown process works. Our judgment and opinion don't enter into it. By issuing a DMCA takedown notice, the claimant is swearing under penalty of perjury that their claim is true and accurate. For that reason, if a notification meets the legal standard, the law requires us to go through the process, even if the situation looks completely bogus to us. (Unfortunately, civil perjury is a criminal charge, and we're not aware of even one case where a US prosecutor could be bothered to bring that charge in response to an abuse of the DMCA, due in part to the difficulty in proving that the DMCA abuse was intentional and not "an accident.")
Therefore, when we receive a DMCA takedown notice, we will forward it to you in its entirety and give you 24 hours to disable access to the allegedly infringing content it references. "Disabling access" to the content doesn't necessarily mean deleting it, although that is one approach. You could also disable the site, change the file or directory permissions, or temporarily move the allegedly-infringing content to your site's "protected" or "private" directories. It doesn't matter how you do it, but you must remove the content by the deadline, or we will have to do it. Our ability to disable access to content usually entails disabling access to an entire site, whether the entire site is allegedly infringing or not. That sucks if there is only a small amount of allegedly infringing content.
Once you have disabled access to the allegedly infringing content, let us know that you've done so. When you do so, you must indicate which of these three courses of action you wish to take:
You accept the allegation of infringement, and you will not restore the infringing content, file a counter-notification, or make any additional infringing content available in the future.
You do not accept the allegation of infringement, but you do not wish to restore the allegedly infringing content or file a counter-notification.
You do not accept the allegation of infringement and that you intend to file a counter-notification under the Act.
If you do not intend to submit a counter-notification, you may wish to include sufficient supporting justification for us to determine whether to hold this incident against you if future allegations arise, as repeated infringement is grounds for adverse termination of your service (as required by US law).
If you don't respond, or if you respond indicating that you intend to file a counter-notification and then don't follow through within two weeks, we will assume you accept the allegation of infringement.
The rest of this FAQ assumes you are filing the counter-notification.
Your counter-notification must be in writing and must contain the following elements, or we will reject it:
An identification of the allegedly infringing material and the location at which the material appeared before it was removed or access to it was disabled.
The following statement: "Under penalty of perjury, I have a good faith belief that the material was removed or disabled as a result of mistake or misidentification. I will accept service of process from the person who provided notification under S.512(c)(1)(C) or an agent of such person."
Your name, address, and telephone number.
One of the following two statements.
If your address is in the United States: "I consent to the jurisdiction of Federal District Court for the judicial district in which my address is located."
If your address is not in the United States: "I consent to the jurisdiction of any United States judicial district in which NFSN, Inc. may be found." (For your reference, this will typically be either the Florida Middle District Court in Orlando, FL, or the Delaware District Court in Wilmington, DE. Both are US Federal District Courts.)
Your physical or electronic signature.
The best ways to submit your counter-notification are email or fax. If you use email, make sure you're sending a scanned copy that shows your physical signature or a PGP-signed email with a signature that can be correlated to your member contact email address.
We are legally required to provide a copy of your counter-notification to the claimant. This means they will know who you are. If you don't want them to be able to identify you, the counter-notification is not an option you can use.
The claimant then has ten days after receiving the counter-notification from us to file an action against you in the appropriate court seeking a court order to restrain you from engaging in infringing activity relating to the allegedly infringing material and notify us that they've done so. If they do not, we will restore access to the material. (In a case where you disabled access yourself, we will restore access to the material by notifying you when it is OK to restore it. Do not under any circumstances restore access to the allegedly infringing content or make it available at a new location without that notification; that'll result in automatic adverse termination of your service.)
This FAQ entry provides general guidance about our DMCA notification takedown and putback processes. It is not a substitute for legal advice. While we encourage everyone to stand up to copyright bullies and push back when the DMCA process is abused, the consequences of filing a spurious counter-notification can be significant. We strongly urge you to consult a legal professional if you find yourself in this situation.
You can get the full text of the Online Copyright Infringement Liability Limitation Act portion of the DMCA here.
Maintenance mode is a way to disable web access to your site while leaving SSH (and FTP, if enabled) access available. It is suitable for use when you need to edit your site, but you don't want people accessing it while you do, for example if you find out you urgently need to apply a security update to a software package you are using for which an exploit is already available, or if you just don't want people accessing the site while you are in the middle of making major changes to it.
If we discover a problem with your site, such as if it is being exploited to send spam due to a vulnerability in software you are running, we will frequently convert your site to maintenance mode to stop the spam outbreak but leave the site accessible to you so you can fix the problem. Once the problem is fixed, you can bring the site back online yourself. (But if we shift your site to maintenance mode, please make sure you solve whatever problem required us to do that before you bring it back online; we have other ways of disabling sites that our members cannot reverse on their own, and we really dislike being forced to use them.)
The message presented when people attempt to access your site is the same one presented if we perform system maintenance that requires us to take your site offline, and can be seen here, so if you need to work on your site discreetly, you do have the option to put it into maintenance mode and blame us.
To tell the difference, check the Site Information page. If it says the site status is "Member Maintenance" then it is under your control. If it says the site status is "System Maintenance" then we are doing something that requires the site to be offline. (Our system is designed to avoid the need to do this in all but a few rare cases.)
To enter or leave Member Maintenance mode, use the relevant link in the "Actions" box on the Site Information page for the site you want to affect. System Maintenance mode is controlled by our system. Your site status will change automatically to this status when such maintenance starts, and change back once the maintenance is complete.
There is a third type of maintenance mode, called "Restricted Maintenance." Most members never encounter this, but when a site has a bad track record of problem behavior (e.g. being hacked to send spam) and the site operator demonstrates unwillingness or inability to resolve the issue, the site will be placed in this mode. There are two ways to get a site out of restricted maintenance: delete it or, if you are a subscription member, open a support issue explaining what you have done to resolve the problem and asking for the site to be reviewed.
If you want to transfer something to an account on someone else's membership, please see this FAQ entry for more details about coordinating the transfer.
We provide two separate sharing options that are very different in terms of power and scope.
The less powerful option is adjunct access. This lets one member of our service share SSH and SFTP access to a site with another member. This is a good option if you just have someone helping you develop the content of one site.
The more powerful option is account sharing. This lets a member share full access to an entire account and all of its contents with another member. This option is suitable for companies and organizations that can't have just one person who has the ability to manage content, or for shared responsibility, for example where one person is primarily paying the bills and someone else is primarily managing the services.
If your bank says your credit card was charged after our system told you the address or security code were incorrect, that is a temporary issue on your bank's end.
Your bank will automatically resolve the issue in a few days.
There is nothing you or we can do to speed that process up.
The longer explanation:
If you enter your card billing address or card verification code incorrectly (as determined by your bank, not by us), we may not be able to accept the transaction. However, the bank that issued your card may place an authorization hold in the amount of the deposit anyway, just because we tried.
These temporary holds often show up in online summaries as "pending activity" or similar. However, your bank will automatically remove them after some period, usually a few days. Only the transactions that we accept and credit to your account will ultimately be charged to your credit card balance.
Some banks clearly display pending charges as separate from settled charges. Other banks do not. If you contact your bank, their customer support may incorrectly claim that the charge is not pending; i.e. that it has been fully processed. It appears to be exceedingly rare for them to be properly trained on the intricacies of credit card transaction processing. Please note that no credit card transaction is fully processed until it is settled in a daily batch in the middle of the following night.
Since such holds are placed by your card-issuing bank, they are entirely beyond our control. We cannot remove them, nor can we accelerate the pace at which your bank removes them. The best way to avoid this situation is to double-check your address information with your billing statement prior to making a deposit, and make sure your card verification code is correct.
Non-production sites are limited to half your total sites (rounded up).
However, to provide maximum flexibility, this limit is not strictly enforced.
If your non-production sites exceed this limit, our system will apply an adjustment charge once per day. This charge equals the number of excess non-production sites multiplied by the difference in daily cost between a non-production site and a production site. It will appear as a charge for "Excess Non-Production Sites" in your account activity and history.
Your total and allowable non-production sites are calculated across your entire membership, not on a per-account basis. E.g., if you have ten sites spread across three accounts, any five sites may be non-production without incurring extra charges.
If you have multiple accounts and excess non-production sites, the charge will be divided proportionally between those accounts. Any remainder will be allocated to an account at random.
If you have many sites eligible for the non-production plan, this charge can eliminate the need to choose some to make production unnecessarily and ensure you are automatically charged the minimum possible for the number of sites you have.
If you prefer to avoid this charge, you can promote your excess sites to a Production plan, consolidate multiple non-production sites with features like per-alias document root, or remove excess Non-Production sites.
If you do log in to our site, the System Status panel consolidates most of your need-to-know information about recent updates and downtimes. If our system appears down, you can also check our offsite status page for updates.
For more significant updates, our primary mechanism for keeping our members informed is our blog. It is relatively low-traffic and is where all important service announcements about our service will appear.
To help you keep up to date without constantly visiting our blog, we offer a couple of useful RSS feeds. There is an RSS feed for the whole blog as well as sub-feeds for News & Announcements, Network Status and Policy Changes that include various announcements about service-affecting maintenance, planned downtimes, and changes to the service that affect all or nearly all of our members, like upgrades that may not be backwards-compatible.
For more detail, the News & Announcements RSS feed includes all the Network Status announcements as well as posts about new service availability, beta test announcements, pricing changes and the like. (Since we try to include everything from Network Status in News & Announcements, it's generally not necessary to follow both feeds.) The News & Announcements feed is the one used to populate our member home page.
These are our primary channels of communication, so we strongly recommend that you follow one or more of them to stay abreast of events affecting you. We try to keep all these channels low-traffic and relevant.
If you want to support two-factor authentication with more than one device at a time, we suggest using a program like 1Password that can securely distribute your 2FA configuration to multiple devices. It is also possible to configure multiple devices at once with the QR code, but that's much harder to keep track of.
First, we will summarize the transfer process, which is straightforward and quick when done properly. After that, we will go into some detail about why it works the way it does.
Resist the urge for the sender to give the recipient their username and password. That's expressly forbidden by our TACOS and will ultimately cause both of you a lot more expense and hassle than it avoids.
The recipient should create a new membership of their own. (Unless they already have one!)
That's it. The whole process usually takes about five minutes of your time to arrange.
It's common for expert web developers and designers to use our service to set up and manage accounts, domains, and sites for third parties. The third party might be an individual (like clients, friends, or relatives) or a group, club, or company. (For the sake of simplicity, we'll call people who do this "web admins," and we'll call the third party the "client" for the rest of this FAQ entry.)
For various reasons, changing the responsible party is sometimes necessary. Maybe a client/designer relationship is ending, or someone is leaving the company or graduating from a school club. This situation, which is often already delicate enough, does need to be handled with special care.
The very first thing is to be very sure you understand the difference between an account and a membership. It helps this type of transfer a lot if all the relevant assets are bundled up in one account on the current web admin's membership. Then, it can then be transferred as a single easy piece to the client's membership. (Most people handling hosting for others already manage assets this way anyway for accounting purposes.)
Transferring assets from the developer's membership to the client's membership (whether neatly bundled in one account or not) must be done while following certain very strict rules about NearlyFreeSpeech.NET memberships:
All memberships belong to individuals, not groups, clubs, companies, etc.
Memberships are non-transferable.
Memberships cannot be created for others.
Memberships must never be shared or accessed by anyone but the named member.
This means that if you are acting as a webmaster for a client, you cannot, for any reason, create or access a membership belonging to them. This specifically includes setting up a new membership on behalf of a client. And they may not access your membership either. So giving them your login and password information and sailing off into the sunset is right out.
The common question at this point is how a non-technical client is supposed to set up and manage a membership and hosting for themselves. The answer is that they are not. Our service is designed to be used by skilled webmasters, and it's often the case that removing the technical expertise of a professional developer without replacing it with an equivalent is simply not viable. If you find yourself in a situation that would wind up with a NearlyFreeSpeech.NET membership in the hands of someone who won't know what to do with it, stop. That probably means the transfer you need to arrange is to a hosting company that offers a lot of tech support (e.g., telephone tech support) and caters specifically to nonspecialists. That's fine; there are a large number of such companies. We would much rather that happen than for someone to end up with a NearlyFreeSpeech.NET member left in the lurch with no idea how to use our service or what our policies are.
For this reason, if we detect a transfer request between two memberships that appear to have been accessed by the same person, we will stop the transfer. Depending on the circumstances, we may refuse to process it entirely. But at a minimum, we will contact both parties and ask them to verify their identity and that they submitted their request themselves. We will further ask the recipient to confirm that they went through the signup process themselves, that they have read and understood (and agreed to) our Terms and Conditions of Service, that they understand the nature of our service, and that they are comfortable managing their membership and account moving forward without any external assistance (including ours). Only if we're satisfied will we allow the transfer to proceed.
That's a lot of extra hassle. However, it's very simple to avoid it completely: just make sure that the transfer recipient sets up their own membership and that neither the sender nor the recipient ever accesses the other's membership.
For more information on transfers and on helping others get set up on our service, we recommend also reading our FAQ entries about organizations and
referrals.
Currently, this is done from the ssh command line. Log in to your site via ssh and run one of the following commands.
To remove TLS from one alias (e.g. www.example.com).
YourPrompt$ nfsn unset-tls www.example.com
To remove TLS from all aliases:
YourPrompt$ nfsn unset-tls '*'
This command takes about five minutes to take effect.
This can also be done by removing and re-adding the alias via the UI, but that approach is significantly more disruptive.
Any application software (e.g. WordPress) running on the site may need to be reconfigured as well.
Please note that we do not recommend removing TLS once you've added it. Doing so may cause problems and security warnings for your site, especially if you have at any point used a Strict-Transport-Security header. In general, you should be able to replace an undesired certificate with a new one without removing it first. Therefore, this command is provided for completeness, testing, and non-production sites.
It is not possible to remove TLS for the shortname.nfshost.com name for your site.
Some domain registrars require you to include the IP addresses of our name servers when setting up your domain. Although this list is subject to change at any time for any reason, here are the IP addresses for all the DNS servers which may serve member domains. Be sure to use the correct name servers for your domain.
ns.phx1.nearlyfreespeech.net
208.94.116.1
ns.phx2.nearlyfreespeech.net
208.94.116.33
ns.phx3.nearlyfreespeech.net
208.94.116.65
ns.phx4.nearlyfreespeech.net
208.94.116.97
ns.phx5.nearlyfreespeech.net
208.94.116.129
ns.phx6.nearlyfreespeech.net
208.94.116.161
ns.phx7.nearlyfreespeech.net
208.94.117.1
ns.phx8.nearlyfreespeech.net
208.94.117.33
If (and only if) you are using our secondary DNS service, one of the following name servers may also apply:
Although this is largely up to you to determine, there are two exceptions.
First, if a site generates revenue of any kind, in any amount, it cannot be a non-production site.
Second, the number of non-production sites you can have is limited to half of your sites, rounded up. If you have more than one site, some of them must be production (or critical) sites regardless of what they're used for. If you have too many non-production sites, our system will apply an Excess Non-Production Sites charge to make up the difference.
Beyond those two criteria, it's your decision. If you have a gut instinct that one of the options is best, you're probably right. If you're not sure, look at the restrictions associated with non-production sites, and the additional custom monitoring associated with critical sites. If your top priority is low cost and you can live with the restrictions, your site is probably non-production. If your top priority is stability, your site is probably production. If your top priority is availability at all costs, your site is probably critical.
Sites that people tend to regard as non-production include (but aren't limited to):
Personal blogs and home pages (that don't generate ad revenue)
Personal resume and portfolio sites for people who change jobs every few years
Experiments and "I want to see if I can set up X" sites
Beta/development versions of another (production) site
Future production sites that are under development and not yet available to the public
Sites that people tend to regard as production include (but aren't limited to):
Most public-facing business, club, and organization sites, whether or not they generate revenue
Blogs that show ads or otherwise generate revenue
Resume & portfolio sites for contractors, consultants, gig workers, and other people who expect frequent traffic that leads to paid work
Active forums with many participants
Sites that people tend to regard as critical include (but aren't limited to):
Any site that generates more than about US$100 per month in revenue
Business sites where business operations depend in any way on the availability of the site
But, to reiterate, as long as you maintain appropriate ratios and follow the revenue rule — that non-production sites may not generate revenue — the choice is yours.
Unbilled storage refers to storage space (for sites or MySQL processes) that our system has recorded as used but which hasn't been billed to your account yet.
The usual reason for this is that the unbilled amount is less than a penny; our system won't bill your account for storage until an individual site or MySQL process accumulates at least a penny's worth. This can cause the "Unbilled" amounts on the Account info panel to be higher than one penny if you have more than one site or MySQL process. E.g. if you have two sites on one account and one has 0.6 pennies worth of unbilled storage and the other has 0.8, your account will show 1.4 cents of unbilled storage, but won't bill you for storage until one or the other gets to the whole penny individually.
The other way you can accrue unbilled storage charges is to allow your account to run out of funds. When an account is empty, storage charges won't be applied, but since we don't immediately delete your content when your account goes empty, each site or MySQL process will continue to accrue unbilled storage until one of two things happens: you make a deposit or the site/MySQL process is deleted. Once you make a deposit, unbilled storage charges in excess of a penny will post to your account. If you delete the site or MySQL process before you add funds, or if your membership expires, associated unbilled storage charges will be discarded along with the content.
If you have large sites or MySQL processes and you leave an account empty for a long time, close to the 30 day limit for example, substantial unbilled storage charges may accrue. You should definitely take this into consideration -- and our system will attempt to warn you about it if applicable -- when adding funds to an account, to prevent further disruptions in service.
Account sharing allows multiple members to share access to and control over a single account. This includes actions like making deposits, renewing domains, and editing websites. It is significantly more powerful than adjunct access.
Account sharing is primarily useful for organizations, where more than one person is involved in the day to day operation of its hosting related services, or even where the one person who is usually involved in those day to day operations has the temerity to get sick or go on vacation.
It can also be useful in cases where a non-expert wants to operate a site with the help of an expert. They can share the account so the expert can adjust DNS settings and manage domain registration as necessary to support the site. It likewise supports setups where one person is paying for things and a different person is doing them.
Account sharing is very powerful, and you should always be very careful that you trust any person with whom you share your account. They essentially become co-owners of the account, with full privileges to do whatever they want with it. That includes, but isn't limited to, transferring funds and assets to accounts of their own, deleting things, or transferring registered domains to other providers.
Once each additional person has set up their own membership, then you can share an account with them from the Account Information panel for that account. Just have them give you their login name and add it to the list of "Members Sharing This Account." To remove another member's shared access, click the "Unshare" button next to their name on the list.
Typically the only thing that will stop you from cancelling your membership is a registered domain. Before you can cancel, any domains you have registered through our service must be transferred away
or you have to wait for them to expire and be deleted.
In the Details box, on the Email Address line, select the Edit button.
On the Update Contact Email Address panel, enter your new email address in the New Email Address box.
Select the appropriate type of update. (But if you want to transfer your hosted services to someone else see this FAQ entry instead.
Use the Start Update button to initiate the change.
We will send an email containing a confirmation code to the address you entered. Use the link in that email to confirm your request, or follow the email instructions to enter the confirmation code manually.
Once you confirm the new email address, it will begin working almost immediately.
If you have NearlyFreeSpeech.NET email forwarding set up to forward messages to your contact address, they will be updated by this process. If you have any domains with RespectMyPrivacy, this process will update those as well.
Each deposit generates an email receipt. If you didn't happen to save that email, you can view a record of your deposit by visiting the "accounts" section of our site, selecting the account in question, and then visiting the "Search Account Activity" link in the "Actions" box. (Note that if you made the deposit within the last 12-24 hours, it might be displayed near the bottom of the account information page under "Current Activity.")
We cannot, under any circumstances, print an invoice. Invoices are only used when the amount of goods/services purchased is known prior to payment, which is not the case with a prepaid service like ours. We do offer detailed records of past account activity via our UI which typically provide the same information as would be contained on an invoice.
Generally, no. Most of the buffoonery that calls itself "penetration testing" is just an attempt to compromise the security and/or availability of our service and/or a member site. We take an extremely dim view of that. It's also a federal crime. We respond to unauthorized "penetration testing" just as we would for any other hacking attempt, ranging from blocking source IPs from accessing our network up to and including contacting the relevant authorities, pressing charges, and seeking civil damages if appropriate. If we find that unauthorized penetration testing was done with a member's cooperation or at a member's direction, that membership will be terminated without warning or refund.
If you do wish to engage in authorized penetration testing, it can be arranged, but the cost is considerable and you must meet significant requirements:
You must be a subscription member to even discuss the possibility. If your site is important enough to require penetration testing, you should be a subscription member anyway.
You must submit a detailed written test plan to us and obtain our approval before testing.
You must submit a certificate of insurance demonstrating applicable coverage both for general liability and professional liability / E&O appropriate for the work you will be performing. The certificate must show current coverage with a per-incident limit of at least $1,000,000 and reflect NFSN, Inc. as an additional insured.
You must agree in writing to share the complete test results with us.
You must schedule all testing at an off-hours time acceptable to us when we can have an engineer available to monitor it. You will be expected to cover all costs associated with that, including overtime, if applicable.
You must provide the source IP address(es) for all testing ahead of time, and should be aware that the engineer monitoring the test will not hesitate to block them if any test activity negatively impacts any site other than the one being tested. You should also anticipate that every packet will be logged.
If you fail to abide by these requirements, or agree to them and fail to follow them (for example if you test outside approved hours, deviate from the approved test plan, or fail to provide results after performing a test), then authorization for future tests is unlikely to be granted.
These requirements are onerous, and reflect that penetration testing is a risky practice that must only be undertaken by skilled, qualified professionals after careful planning. (And yes, people with legitimate need can and do meet these requirements.) If the firm you hire to perform the test balks at these requirements, they are not qualified. If you have a legitimate need, please feel free to contact us; we can direct you to qualified firms.
If these requirements are too onerous, or if the cost is too high (which would be odd; while substantial by our standards, they will be a rounding error compared to the cost of having a proper test performed), that is a good sign that your site is not appropriate for penetration testing.
We do regularly perform and have others perform penetration tests on our own network in order to ensure that our service is as secure as possible. No accesses to member web sites are performed by these tests, but representative sites managed by us are thoroughly tested in addition to our own production sites.
Select the "Transfer Funds Between Accounts" action from the Actions box.
Select the "To another member's account" transfer type.
Enter the recipient's account number in the "Destination Account" text box.
Complete the transfer.
Please keep in mind that we cannot offer you any guarantee as to how the recipient will use those funds. Also, due to our privacy policy, we are unable to answer questions like "how much is needed to get the site example.nfshost.com back online?" Also keep in mind that we are not a payment service like PayPal; per our Terms and Conditions of Service, funds transferred between members in this fashion become nonrefundable.
By default, our system includes two low-balance warnings for each account: one at $5.00 and one at $1.00. When your balance falls below a warning level, an email will be generated to your member contact email address. Once a balance warning has been triggered, it will not trigger again until the balance has exceeded the level of the warning for at least one minute.
Because one size does not fit all, account balance warnings are fully customizable. You can set up as many balance warnings as you want, at any level you want up to your current balance, and configure whether they are sent by email or, if you have set an SMS number on the Profile tab, by both email and SMS.
You can also remove the default warnings if you want, although we strongly recommend against doing so unless and until you add other warnings that you feel better suit your expected usage.
To calculate good intervals for warning levels, we recommend that you review your use of our service after a few months and figure out about how much it is costing per week and per month, then set at least two reminders: one when your remaining balance should last about another month, and one when it should last about another week. Then, we advise that you maintain a balance high enough to keep both warnings active at all times; the second, lower warning should serve as a fallback if you forget about or miss the first one. But this is just a recommendation; you are free to manage your warnings however you want.
As a last-ditch reminder, our system will also contact you by email (and SMS if configured) when your account runs completely out of funds. This message cannot be configured or disabled.
No, we do not. Our service is pay-for-what-you-use in nature and each member is responsible for all fees their use of our service incurs. We cannot provide credits or refunds after the fact for services that were provided as configured by the member.
We have no flexibility in this area; all of our vendors charge us on exactly the same terms.
We hate for that to happen; maintaining high-quality documentation is very important to us. Occasionally, however, we slip up. If you find such a mistake please report it to us. We'll check it out and if we agree that it's a typo or mistake in our documentation, and we fix it as a result of your report, we'll give you a $1.00 service credit as a bounty. (Full details can be found on the typo bounty page.)
For site content, we use 3-way mirroring to protect live data, and we take snapshots twice per day. For member MySQL processes, we have less flexibility, but we still take daily full backups of data from each process.
We maintain both local and offsite copies of those backups and age them out on a space-available basis so that, at any given time, we have many viable restore-points available.
We also maintain both live and offsite replicas of the core databases containing member and account data.
Our goal is that in the event of a serious catastrophe that destroyed our primary datacenter, data loss would be limited to everything since the most recent backup, which averages 6 hours for sites and 12 hours for MySQL processes.
However, if we actually had to restore everyone's backups, the amount of data involved is substantial. It would take a really long time, especially if we had to rebuild our infrastructure from scratch first. You might reasonably want access to a copy of your data sooner than we could provide it. We therefore strongly encourage every member to make their own backups.
Yes. Your site will incur storage charges even if it is disabled. (Being disabled doesn't take up any less space.)
Daily site charges also continue to apply unless the site is also set to the "Non-Production" billing plan.
Nothing stops you from converting a Production site to a Non-Production site to avoid the daily charge while disabled. But disabling is really only designed to be an emergency short-term measure, so that is an off-label use. If you want to avoid all charges from a site you know you won't need for awhile, it's best to take a backup and then remove it.
We're doing the best job we can to ensure that there is no catch. But of course, there's always fine print. Ours is a pay-for-what-you-use infrastructure, and in order to convey your deposits into your account and then keep track of them, we have to maintain our billing infrastructure, do our accounting, file our taxes, and deal with payment compliance issues and fraud. All that adds up, so we have to charge you a small deposit fee.
We do not profit from deposit fees.
The base deposit fee is exactly the same for all members and payment methods. However, before charging you this fee, we offset it as much as we can by applying a variable instant rebate. This helps ensure that small deposits remain cost-effective and helps us tweak the system to make sure deposit fees are distributed fairly without overcharging anyone.
If the deposit fee and instant rebate system seems unnecessarily complicated, it is and we apologize. It is unfortunately necessary in order to provide you with the best possible pricing without running afoul of the conditions imposed upon us by our payment processors. We're constantly on the lookout for ways to reduce (or simplify!) these administrative costs, because they don't help us and they don't help you.
Credit and debit cards: Visa, Mastercard, Amex, Discover, JCB and Diner's Club
PayPal
Mailed-in checks and money orders
Credit card and PayPal are processed immediately. Mail-in deposits take longer.
Some prepaid cards work with our service and some do not. Whether an individual brand of prepaid card will work is at the discretion of the card issuer, not us, so although some do work, we don't recommend using them.
We do not accept cash payments for the simple reason that cash sent through the mail all-too-frequently does not reach its destination. Even the US Postal Service acknowledges this and officially discourages the practice. You may use cash to obtain money orders from the United States Postal Service, Western Union, and many other vendors in the United States. Internationally, we recommend the use of American Express worldwide money orders denominated in US Dollars.
We do not accept any forms of payment not listed here.
If you wish to pay us anonymously, see this FAQ entry for more information.
A member may easily request cancelation of their service at any time from the Profile tab in our member interface.
When a membership is canceled, we will return the prepaid balance remaining in your account—all of it.* Since we provide a pay-as-you-go service (for almost everything but domain registration and privacy), you're only responsible for the cost of services we have already provided. There's no "OK, but your cancellation won't be effective until the beginning of the next billing cycle." or "OK, we'll cancel you right now, but you agreed to pay for a zillion years of hosting in advance, so you don't get a refund." We'll process your cancellation request as soon as possible and (in most cases) refund your remaining balance at that point.
If you try our service and figure out the same day (by 9 PM US Eastern time) that it is not right for you, let us know immediately. Sometimes, but not always, we can void your transaction so that it will be as if you were never even charged. We can't promise that, but if you let us know fast enough, we will do our best for you.
There are rare cases where funds may be nonrefundable:
Payments were made by a third party. (We are not a money transfer service!)
Payments were transferred to your account from another member. (But you're welcome to transfer them back, with their permission.)
We cannot issue a partial refund of your prepaid balance. We can only issue a refund in conjunction with the close of your membership, and it will be for the full remaining balance unless you specify otherwise.
Also, ICANN does not allow registered domains to be abandoned. If you have any domains registered through us, you must transfer them to another person or registrar before requesting cancellation. (Fees paid for domain registration are typically nonrefundable.)
*If we have to mail you a check, there will be a small charge deducted from your balance first, and we won't issue a refund by check for a balance less than the charge.
Our primary requirements in this area are as follows:
Your content must be legal according to the laws of the United States.
You may not use our service to violate your local laws.*
If you have questions about whether your proposed site is legal, you need to consult an attorney. Under no circumstances can we give a legal opinion or advice, nor can we make binding statements about hypothetical sites and circumstances.
*You must obey all applicable local laws unless you get our prior express consent in writing. We do provide anonymous hosting of content that violates local government censorship laws at our sole discretion in cases outside the United States where we feel government censorship is contrary to the cause of freedom.
If you have questions about our willingness to put up with controversial or unpopular sites that are nonetheless legal, we invite you to review our Abuse @ NearlyFreeSpeech.NET page.
Your services will be automatically disabled. As soon as you add more, it'll come back, but that can take a few minutes and that often feels like the longest few minutes of your life, so we recommend using and customizing the account balance warning system (which supports both email and SMS) to keep track of things before they go that far.
If you don't add more funds right away, things will hang around for at least 30 days. You can add more funds at any point during that period and get it all back.
If you haven't added funds after the 30 days, we'll start cleaning things up. Services paid for by that account, including all hosted content, will be removed. If you don't have any registered domains on that account, the account will be removed a few days later.
If 30 days is not a long enough grace period, we offer a feature called "suspended animation" that can help you extend the retention of your content when your balance runs low.
That setting can be enabled and managed from the "Suspended Animation Threshold " line of the Account Information box on the page for your account under the Accounts tab.
If you do have one or more registered domains, they will persist until they complete the expiration/deletion process or are transferred elsewhere. That will keep the relevant account and your membership open so that you can continue to manage them.
You can also view (and configure) how long your membership is retained after your last account expires in the "Retention Time" line of the "Details" box on the Profile tab. As long as your membership continues to exist, you can request that we attempt to recover deleted content. (A fee applies for this service.) Recoveries of this type are generally successful if requested within several months of deletion.
Once your membership is deleted, however, that's it.
In addition to all of the options available to baseline members, people who have opted in to subscription membership are eligible for individual private support via email and our ticket system. Our individual private support option is informed by our own support experiences:
There are no "level 1" techs triaging requests. Whoever answers your inquiry knows what they're doing.
We try to answer questions quickly during our standard support hours, maintaining an average response time of less than two hours.
If we need to research the answer to your question (within reason) we will.
We never cut-and-paste "canned answers" that may or may not address the question you actually asked. (Though if you ask a question covered in our member FAQ and don't indicate that you read it, you may be gently directed to it.)
Don't be surprised if you write in for support a second time, and we remember you from the first time. We are not interchangeable parts, and neither are you.
Baseline membership reflects that our do-it-yourself service is designed to be used without individual support. Consequently, support options are limited, but typically unnecessary.
Most of the information members need is maintained in a detailed technical FAQ (available here if you are not yet a member).
When members need a little more help, they generally turn to our community support options. We have a member forum populated by some very, very smart people (including our staff), and members can view and contribute to a wiki that provides a rich variety of perspectives on tips, tricks, and how to get various things to work.
We also offer a specialized type of support, called assistance requests, for specific predefined actions that you need us to perform on your behalf. These are very limited in scope, highly automated, and are often designed to smooth over features that don't have a UI in our control panel, because they are specialized or rarely used. Baseline members also have the ability to report perceived problems with the system, although that channel is one-way; it is not a way to obtain help or support.
These options are sufficient for almost all of our members. Those looking for more can evaluate whether the individual support option included with subscription membership meets their needs.
The same thing that happens if your site uses less than $0.01 in a day, in a week, or in a year: it keeps going until it does.
We aren't really interested in months. The amount of bandwidth you use is carried over as long as it takes until you accumulate a penny's worth of usage, even if that takes a month or more.
No, that would be silly. Since we bill primarily based on resource usage, if most of our services go down, you'll never be charged for them in the first place! We charge you primarily based on the bandwidth and resources you use. If the service is down... well, you aren't using much bandwidth or resources!
This business model has another profound consequence. In the event of a service failure, our revenue craters on the spot until it is fixed. The technical term for that is "motivation." For this reason, we do not offer any service level agreements or uptime guarantees other than "you will get the very best we have to offer."
By way of disclaimer, the above applies only to bandwidth and resource charges. Storage and other charges have always continued to apply during network outages. We don't know what we would do if we ever had a storage outage that resulted in data loss, since it's never happened. If it ever does, we'll try to do the right thing.
A "membership" represents you as an individual person (not a company, group, club, or organization). It's how you identify yourself to us, and how you access our services. If you're a US worker, it's like your social security number except, you know, less social and more secure. And, in most cases, less number-y.
An "account" is how you pay for our services. It contains the funds that you use to purchase hosting. You'll need at least one. You may create more, if you want, but you don't have to. Accounts also hold hosting-related assets, like web sites, domains, and database processes. Just as one membership can have several accounts, one account can fund several different assets.
Accounts also contain contact information about their owners, which may or may not be the member who manages the account. A web designer managing an account for a client would be a good example of a case where the member who manages the account is not the owner. Similarly, a company might own an account, even though it's managed from the company's webmaster's membership. Keep in mind that from our perspective, regardless of account ownership, the member is the only representative of the owner authorized to access the account. (There's no point in having any other policy, since the member can change the account's contact information at any time.)
People use accounts to group related stuff together, to separate business and personal expenses, or to keep track of multiple clients. All sorts of reasons. Other people are perfectly happy to jam everything into one account and have only one balance to keep track of.
It's a little like a bank. You are one person, but you might have two savings accounts: one for college, and one for "rainy days." The bank (if they know you at all these days) knows that you are just one person, and you have your social security number (membership) to prove it.
Unlike accounts, you may not have more than one membership. That would be like opening an account at your bank, then going out to your car, putting on a fake moustache, and going back in to open a second account.* Even if you could, why? Likewise, you cannot go into the bank, give them someone else's social security number, and open an account in their name.** So please don't open memberships for other people here.
*At least, we assume it's like that, but we've never actually tried it. Our bank has a pretty good sense of humor, but why push our luck?
**Sense of humor or not, we're pretty sure that's a felony.
Yes. CGI processes and individual ssh commands are limited to two to five minutes of CPU time, and PHP requests are limited to three minutes of wall-clock time by default.
These restrictions are designed to catch runaway processes, not to interfere with ordinary usage. "Stock" web applications, specifically including phpBB and WordPress, simply do not use enough resources to encounter these limits. Who would wait three minutes for a web page to load anyway?
If you have a need for longer-running processes (e.g. for non-interactive use), there is usually a way to make that work or adjust our system settings to accommodate it.
Although we do not impose an overall specific per-site CPU limit, ours is a shared hosting service. We try to accommodate individual needs, particularly on plans where you pay for the resources you use, but we do reserve that right (and responsibility) to limit anything that causes disruption to others. If you have a site on one of our older plans that does not include a resource-billing component, attempts to use large amounts of resources are more likely to encounter limits depending on total available resources.
Yes, but. Because of the ever-present threat of spam, we monitor email usage very closely. Therefore, you should expect an amount of scrutiny directly proportional to the volume of email you send.
It is also very important to be aware of potential vulnerabilities introduced by email-enabled web pages. In particular, generic PHP "feedback" form scripts have proven to be very popular targets for spammers, who can find and exploit them automatically. You should be extremely cautious, and make sure that any email-enabled web sites you create are safe from exploit.
We will hold you responsible for email activity caused by your site, whether you intended to allow it or not. If a spammer exploits a script on your site to send spam, we will have to clean up the mess. At a minimum, that will probably entail temporarily disabling your site, and it may result in additional charges for you.
Please be aware that when we address questions of this nature, we cannot speak to hypothetical situations, nor can we guess what we would have done in a situation where we were not involved. Nor we can offer you legal advice.
In the United States, the Digital Millennium Copyright Act (DMCA) defines the process by which a copyright holder can request that material be removed. In such cases, a provider is legally obligated to remove the allegedly infringing material without judging the merits of the claim. It is essentially done on the copyright holder's sworn say-so.
However, the DMCA also governs the process for restoring material, and that process is similarly rubber-stamp on the part of the service provider. Once that's done, it becomes a matter for the courts, not the service provider.
In this regard, the DMCA is a good law for us and for you. (Although it can and does suck in many areas, this isn't one of them.) The DMCA is, in part, supposed to protect you from capricious decisions made by the service provider based on some subset of the facts. At no point does or should an Internet service provider investigate or make judgment calls about complex copyright law and questions of what might be infringing. (We specialize in server processes, not process servers.) The DMCA gives us (and you) a certain (non-perfect) confidence that the copyright owner's claim has at least some legitimacy, and provides decent protection (once you get over the initial take-down hurdle) against the use of false claims of copyright infringement to suppress legitimate content.
If you wish to host a controversial site in the US, it behooves you to know the law, particularly this one, and how to use it to your advantage in the event of a dispute. You should also be prepared for a downtime of some or all "allegedly infringing" material for a couple of weeks if the copyright owner wants to fight.
We adhere to the entire law very closely. We do not generally pull the plug on an entire site if, for example, someone claims that a single graphic is infringing. We do our best to remove only the content that the copyright owner specifically identifies as allegedly infringing -- usually by allowing you to handle it yourself unless you decline or fail to do so. We allow and encourage the use of the "putback notification" process when material is incorrectly identified as infringing. But we do not automatically terminate a member's service merely for receiving a complaint alleging infringement. (However, actually infringing someone's copyright does violate our TACOS and will generally result in immediate termination.)
Keep in mind that while we aren't lawyers, neither are we idiots. We can tell the difference between people harassing our members via the DMCA and cases where our service is genuinely being misused, and we can adjust our attitude accordingly. Fortunately, both of these cases are very rare.
In most cases, we do not allow our members to remain anonymous to us.
In general, the concern is that information not be disclosed to third parties. Our industry-leading privacy policy reflects our commitment not to let that happen. Therefore, from our perspective, there are very few legitimate reasons why a member would need to conceal his or her identity from us. Most people who request anonymous hosting are attempting to perpetrate fraud (on us or on the public) or wish to escape accountability for their actions.
At NearlyFreeSpeech.NET, we believe that with great power comes great responsibility, so we take a dim view of such behavior. For that reason, our TACOS require our members to provide complete and correct contact information, and requests for anonymous hosting are typically denied.
However, we do make one important exception. If you live outside the United States and can demonstrate that the site you wish to host would put you at significant, legitimate risk of retaliation from a government with a documented track record of reprisal against people who speak out against it, we may be able to help. Anonymous hosting is serious business; it can be one component of a coordinated plan to protect you and your family from torture and murder. It's absolutely not an option you can use to dodge lawsuits or unpopularity arising from hosted material.
If you feel you need this level of protection, please contact us, taking appropriate privacy precautions with respect to your correspondence. Be sure to explain where you live, what you want to host, and why you feel hosting the material anonymously is the only way to guarantee your safety. Be very specific; you will need to explain your situation in enough detail so we can make an informed decision. We may, in our sole discretion, decide to waive the contact information requirement in exchange for periodic reviews of your site content by NearlyFreeSpeech.NET personnel to verify that your usage of the service is consistent with your claims. Please be aware that even if we approve your request, paying anonymously is extremely difficult.
We are not able to provide anonymous hosting to residents of the United States under any circumstances.
Please don't attempt to circumvent our restrictions on anonymous hosting by using fake contact information. Sooner or later we'll figure it out and terminate your membership. And, since you gave us fake information, we won't even be able to give you a refund.
Not directly. We are a shared hosting provider. Credit card issuers impose security requirements on accepting credit cards that prevent you from requesting or storing credit card information on any shared server unless very specific criteria ("PCI DSS requirement A.1") exist and have been audited. It is our opinion that the criteria as written require VPS-type services, which we are not.
Therefore to accept credit cards and most other payments, you will need to use a third-party secure checkout service. The most common services all work with our service, and we don't have any particular recommendations.
These sites will be abused within minutes of discovery, and discovery is pretty much automated. It saves time to say "no" up front rather than wait and shut it down after a problem.
There aren't any circumstances where an IRC proxy or bot is allowable, and you will find most common IRC ports firewalled on our network.
If you need to set up a private web proxy on your site for your personal use that is appropriately access-limited, that is no problem as long as your use complies with our Terms & Conditions of Service. (This does not include using our SSH server as a Socks or HTTP proxy. Doing so is strictly prohibited.)
URL shorteners
URL shorteners are, unfortunately, a lot more fun to write than they are to maintain. If you want to set up a URL shortener for your personal use, that's fine. If you let the general public submit URLs to it, expect us to shut it down the first time it gets exploited. (And it will get exploited.)
Properly run URL shorteners aren't successful because they have the shortest or cleverest URL; they're successful because they have a team of people working 24x365, proactively and reactively, to prevent and mitigate abuse. If you have such a team and want to run a public URL shortener on our service, please contact us for special arrangements. If you don't have such a team, you'll have to find another host that's less concerned about the Internet's welfare.
"Unmoderated" sites
You are responsible for your site's content. If you allow the Internet public to post content to your site, that's on you. If someone posts content to your site that violates our Terms & Conditions of Service, you have violated our Terms & Conditions of Service. You are the person we will hold accountable.
Sites typically avoid this through steps like verified user registration, holding some or all posts for approval, automated content scanning (e.g., PhotoDNA), and human moderators.
Like URL shorteners, successful sites that eschew one or more of those precautions are successful because they have an aggressive moderation team large enough to provide 24x365 coverage. Like with URL shorteners, if you have such a team and want to run this type of site, please contact us for special arrangements. If you want to run such a site without adequate moderation, you'll need to do so elsewhere.
These policies don't mean you can't run sites that get any complaints or are ever abused by others. They mean that we are not your content moderators. If you run this type of site and we get a complaint about prohibited content on your site, we want to see that you have already taken care of it by the time we investigate.
Memberships represent individual people. (The law calls this "a natural person." At NearlyFreeSpeech.NET at least, corporations are not people.) A company, club, or organization (we'll go with "company" for the rest of this FAQ entry, but it applies just as well to clubs, organizations, or other types of groups) has no arms, fingers, and eyes and cannot read our Terms and Conditions of Service or complete our signup form.
If you're signing up to host stuff for any kind of organization in which you're not the sole participant, you still have to create your membership as yourself, at which point you, personally, agree to adhere to our Terms and Conditions of Service. This is not too different from opening a company bank account; you still have to give them your own ID and sign the signature card and checks with your own name, not "President" or "Company Name, Inc."
It is very important to understand that once you create a membership for yourself, it's yours. (To reiterate the above, your membership represents you as an individual.) Although you can cancel your membership, or it can expire if you don't have any accounts or services for awhile, you can never give it away, nor ever let anyone else access it, just like you can't give away your personhood, nor allow other people to pretend to be you. This means we do not allow multiple people to simultaneously manage one membership. We are simply not equipped to handle disputes where multiple people are claiming to be in charge and giving us conflicting instructions. There must always be one person with the final say, and that is the person who, in the event of a dispute, can produce photo ID matching the name on the membership.
After you create your membership, using your own name, you will then have the opportunity to create an account. (Actually you can use your membership to create as many accounts as you want, just like you can have multiple accounts at the same bank.) This is the step where, as the representative of a company, you should be very cautious. You should fill out the account contact information to reflect that of the company, not yourself. This indicates that while you manage the account, the company owns it.
After you fund the company's account, you will be able to set up whatever funds, sites, domains, and other services we offer that the company needs. All of those things attach to the account to make up a neat little package of related stuff. That becomes important if you ever need to transfer control to someone else, because it makes that very easy.
If you need to share responsibility for services here with other people from your company, that is also easily done. Other people from the company can set up memberships of their own. Then, you can share access to a single site or a whole account with them.
If/when the day comes that you need to hand over management of the company's stuff to someone else, it's a very straightforward process. The person taking over simply creates a membership for themselves (again, as an individual, in their own name), at which point they read and agree to our Terms and Conditions of Service. (That part is really, really important.) Then, the company's account has a 12-digit account number like A1B2-C3D4E5F6 you can use to identify it. Give the other person that number, and then each of you should send a free assistance request to us through the member interface asking to move the company's account from the old manager's membership to the new one. The account, and all the sites/domains/databases it contains get moved over in one easy step. It's very easy to do, and can be handled in a few minutes without any downtime or interruption of service. If you have other stuff hosted in a separate account on the same membership, it won't be affected.
Usually. However, we do handle these issues on a case-by-case basis, considering several important factors.
First, we look at who is the target of the court order. Some court orders target you as the site operator, and some target your hosting provider.
If a court orders us to take the material down and that court has jurisdiction over us, the material comes down. We uphold United States law at all times, end of story. If the court does not have jurisdiction over us, we typically request that the order be domesticated before implementing it.
If a court orders you to take the material down, it's a bit more complicated. We will then consider whether the court has jurisdiction over you due to citizenship or residency. If they do, we will typically prohibit you from using our service to violate the court order. If there's a court order against your content, you need to fight the order, not try to use the Internet to evade it.
Some countries' legal systems claim that their courts can exercise jurisdiction over any content visible inside that country, regardless of where it is hosted. We repudiate that legal theory. We do not accept orders from courts that cannot exercise personal jurisdiction over us or you unless they have been properly domesticated. US law frequently bars the domestication of such orders. (However, if Atlantis instead requires all Atlantean ISPs to block access to your site, that is not something we're likely to be able to help with.)
We will also consider the free speech implications of the order. However, many people don't understand how limited this is. Typically, we will only consider free speech-based arguments when the site is about the government issuing the court order. I.e., we would be very likely to disregard a court order from Atlantis requiring the removal of content critical of the government of Atlantis. We would be significantly less likely to disregard a court order from Atlantis requiring you to remove material that the Atlantis court found defamatory of an Atlantis citizen if you are also an Atlantis citizen or resident. Using our service is not a way to opt out of your country's laws.
While we will consider whether a foreign court order is a travesty of justice, it is one of the least influential factors. It rarely comes into play.
One factor we do not consider at all is your opinion. We are not interested in how justified you feel your actions are, how messed up your country's laws are, how easy/unfair/one-sided you feel it is to get such an order in your country, what an ignorant jerk you think the judge was, or how sure you are that they're all out to get you. If you agreed with the order and the process, you'd take the material down yourself; we'd never hear about it. Beyond that, your opinion ceases to have any probative value. Sorry if that's hard to hear.
When we deal with court orders from your jurisdiction, and you are outside the US, it is often helpful for you to make your attorney available to us (at your expense) to answer questions about the matter. If you got a court order issued against you in your own country, but you don't have qualified legal representation, it will be somewhat more difficult for us to take you seriously.
To reiterate the most important statement at the top, we handle all situations on a case-by-case basis. We will not guarantee any specific response, nor will we even guarantee that we will handle all cases as described here. However, we have been at this for many years. The guidelines above have served our goal of staunchly defending freedom of expression without letting the Internet collapse into total anarchy.
In all cases, the indemnification provisions of our Terms and Conditions of Service require you to pay any legal expenses we incur in handling or responding to court orders related to your services with us.
No. We are entirely focused on web hosting and our Terms and Conditions of Service expressly forbid the use of our ssh server for any purpose other than maintaining content hosted here. That prohibition definitely includes using our ssh server as any kind of web or SOCKS proxy for accessing the Internet.
We try to run an open system that provides our members with the most powerful tools for managing their content. As a result, we allow outbound network connections from the ssh server for people who need to move content from/to elsewhere, and we allow ssh port forwarding so people can access their MySQL processes from offsite and so that they can securely access their own sites hosted here.
However, we can and do check for outbound network connections that use our ssh subsystem as a proxy, and our system automatically kills them. Furthermore, we may be forced to take appropriate action if we observe repeated or blatant attempts to misuse our system in this way, including but not limited to revoking ssh access (which will require you to use our paid support to regain) or, in extreme cases, terminating a membership.
Our Terms and Conditions of Service require that accurate contact information is provided for all memberships; free speech is a responsibility as well as a right and part of that responsibility is that you may be held accountable for what you say. Supplemental verification is any step we take to verify your contact information above and beyond our usual policy of trusting what you enter when you sign up for and use our service.
There is a huge correlation between people who provide fake contact info and problems like payment fraud and illegal content. So if during the ordinary course of providing service we find a clear and specific reason to question whether accurate information has been provided, then we get into supplemental verification. To give an extreme example, if you tell us you're John Smith from Ontario, Canada, but pay with Bob Jones' credit card with a billing address in California, and you're logging in from Nigeria, we're probably going to give that a second look.
Depending on the situation, we may inquire about some or all observed discrepancies. That's usually enough to take care of it. In a handful of very rare cases -- about 0.01% of members -- we wind up asking for ID. In those extreme cases, generally any government-issued ID, like a driver's license or passport, is suitable for that purpose, but that comes up so rarely that we're very flexible in handling it on a case-by-case basis.
Typically any problem in this area is easily resolved. If not, it's for one of two reasons. Most of the time the membership was blatant fraud (stolen credit card, illegal content, etc). But sometimes the person involved says something to the effect of "I know your policy, but I don't agree with it, so I won't follow it." The nature of our Terms and Conditions of Service is that if someone refuses to abide by the Terms and Conditions, we will refuse to provide the Services, so that is not an ideological position that is compatible with use of our hosting. Importantly, it may also impair the ability to get a refund. (So if you're thinking about signing up with fake contact information, please don't. It'll eventually end in tears. Yours.)
Supplemental verification is also triggered anytime someone claims they are a member of our service but has neither the login information nor access to the contact email address. In those cases, we skip straight to asking for ID to establish the rightful member. (And naturally anyone who provided fake contact info and winds up in that situation is pretty much out of luck.)
It's also worth remembering that we also have an industry-leading privacy policy that protects contact information from disclosure without a legal requirement to do so, and that we may also offer anonymous hosting with advance written permission in certain very rare cases where personal safety is an issue.
We cannot process any instructions with respect to a membership via email. This includes, but is not limited to, requests to cancel, to accept payments, to register, renew, or transfer domains, to disable content, or to remove anything.
Email is not secure. Anyone who knows your email address can send an email that appears to be from you. Some people don't even bother using your email address when pretending to be you. We routinely receive emailed requests to do stuff that clearly aren't from the member. But the scary ones are the ones that look like they are from the member but turn out not to be.
Even when we're pretty sure you're you and we believe there would be little risk in doing so, we cannot process an email request. After all, we could be wrong. And even if we're not, we also need to take reasonable steps to protect not only you, but also ourselves.
So, on our system, the way you prove you're you is to log in with your member login name and password (and, optionally, a two-factor device).
If you have a subscription membership, you can submit requests via email if you want, but you'll still have to click a link, log in, and confirm that the message really came from you. (Which basically copies it into our support system as if you had submitted it from our site.) That does introduce delays, so you'll generally get faster response if you send such requests directly from the support tab. Please note the option for individual email-based support is only available to subscription members. Baseline members should check the support tab for community support and self-support options.
No. Once a membership has been closed, nothing can be recovered.
The permanent deletion of services, content, and account information is an important part of the implementation of our privacy policy, designed to let former customers be confident that they haven't left hidden copies of their data behind.
Closing a membership also entails removing enough of your personal information that even if recovery were possible, we would have no way of proving you are the right person to recover it for.
As such, once a membership is closed it is permanently gone and any associated information, content, domains, or other services cannot be recovered. (You are, of course, welcome and encouraged to re-create things from your own backups if you choose to set up a new membership with us.)
Because we believe in free speech, we host a small amount of offensive content. Some days, that's really hard to do. There are views expressed using our service that we find personally repugnant. (Although we don't host as much of that type of content as one might expect, given our extremely broad Terms & Conditions of Service. The simple fact is that our service is for smart people, which disproportionately excludes people who hold those types of views.)
Nonetheless, our content policy does occasionally put us in a position of accepting money to host sites we find abhorrent. But we have no interest in profiting from sites like that. For that reason, since our founding in 2002, we have what we have more recently started calling the MFFAM policy: Morons Funding the Fight Against Morons.
When we find a repugnant site on our service, we mark the account. We receive reports about all payments to such accounts, and we take a portion of that money larger than the amount of estimated profit and we donate it to the best organization we can find. The best organization in any given case meets two criteria:
The recipient organization does share our values.
The recipient organization is as opposite (and hopefully as offensive) as possible to the site operator that funded the donation.
Examples of organizations that have received funding over the years include the Anti-Defamation League, the Southern Poverty Law Center, local chapters of the NAACP, the National Bail Fund Network, the American Immigration Council, the Trevor Project, and others.
This policy isn't perfect by any means, but neither is the world we live in. MFFAM does let us help the organizations that we hope will eventually get us closer to that perfect world. It helps the people who operate repugnant sites understand that they are here because we tolerate them... barely... not because we endorse them or their views. It also does a pretty decent job of further thinning out the number of such sites, as a fair number of people who run them only believe in free speech when they're the ones talking.
A site's "realm" or "software realm" refers to the combined collection of all the operating system files, programming languages, and third-party applications present in its environment. These are the tools available to your site for web applications, and for use over ssh.
Some people want the latest and greatest versions of applications, particularly programming languages, especially while they are developing a new site. Others strongly prefer things stay as stable as possible so they don't have to deal with their site breaking every time a non-backward-compatible change gets made by some application developer, especially once their site is up and working.
Likewise, security updates always run the risk of breaking things. Some people prefer to receive security updates immediately to minimize the risk of exposure. Other people prefer to defer updates to a time of their choosing, so they can deal with any problems that result, to minimize the risk of downtime.
Because these desires conflict, we provide multiple types of site realms. They are broadly divided into the following types:
Stable/Current
This is the default realm assigned to new sites. It receives only security updates and important (i.e. "stuff is broken") fixes. If you don't know which realm to choose, choose the Stable/Current realm.
Stable/Upcoming
This is a newer stable realm that will become the default for new sites in the future. It receives only security updates, important (i.e. "stuff is broken") fixes, and (rarely) some non-disruptive new package requests. If you want to get your stuff working in a stable environment that will receive fixes for as long as possible, choose this.
Beta
This is a realm that receives frequent updates (as often as weekly). Although it won't become stable, it serves as a blueprint for future stable realms. New packages will be installed into a beta realm first. Beta realms also receive frequent updates, including security fixes, bug fixes, and upgrades to installed packages. Programming languages and other software may receive frequent upgrades, some of which may impair backwards compatibility, without advanced notice.
Experimental
This is a realm that is not designed to become stable. It contains bleeding-edge languages or software that are grossly incompatible with other realms. Experimental realms may receive large, potentially incompatible, updates at any time. Experimental realms are not supported or recommended for any production usage.
Stable/Deprecated
This is an older stable realm that is still supported but will be obsolete soon. Once a realm becomes obsolete, any sites still using it will be automatically moved to the current Stable/Upcoming realm. Deprecated realms receive no updates.
We add new stable realms based on the then-current beta realm about every three months. These new realms are stable and reliable but remain "Upcoming" for about three months to shake out any weird defects or bugs before becoming the current stable realm. Newly-created sites will start in the current stable realm and, by default, when a new realm becomes current, sites in older realms will be automatically migrated to it.
A site's schedule for automatic realm upgrades can be adjusted via the "Realm Updates" setting in the "Config Information" box on the Site Information Panel. This gives you some control over when to upgrade. If you select the "late" update option, we recommend that you upgrade your site's realm manually about every six months to avoid falling too far behind. (The farther behind you fall, the greater the likelihood of problems when you update.) Although rare, compatibility issues are possible, so it's best to do this at a time when you are ready to deal with them.
You can also switch between available site realms, or get a list of currently-supported realms, by selecting "Edit" on the "Software Realm" line of the same box.
Caution: This is not a subtle change; if you're logged in to ssh when you change realms, it will attempt to kick you off. It is a little like rebooting. So make sure you have saved your work!
By default, your site is set up with secure default permissions that don't allow web applications to write files anywhere except in /tmp. You must set permissions to allow any additional locations to be written.
In order for a PHP or CGI script, or a daemon processes run as the "web" user, to write to a file, the "web" user must have write access to that file. There are two ways to accomplish this.
Set the file to be owned by the web group and set the permissions to allow group-writes. (E.g. chgrp web example.file and either chmod g+w example.file or chmod 664 example.file from the command line.)
Set the file to allow any writes. (E.g. either chmod a+w example.file or chmod 666 example.file from the command line.)
In order for a script or web process to create a file, it's the permissions of the directory in which the file is to be created that matter. To allow this, do either of the following:
Set the parent directory to be owned by the web group and allow group writes. (E.g. to create /parent/dir/example.file, first chgrp web /parent/dir and then either chmod g+w /parent/dir or chmod 775 /parent/dir from the command line.)
Set the parent directory to allow any writes. (E.g. to create /parent/dir/example.file, do either chmod a+w /parent/dir or chmod 777 /parent/dir from the command line.)
The choice of whether to use group-write or all-write is one of personal preference. There is no meaningful difference on our system at this time. Likewise, the choice of semantic ("a+w") vs. octal (777) is one of personal preference. Just be careful not to set directories to 666 permissions, as they will not work correctly and the result can be very confusing.
If you look online, you may find advice telling you to set all directories to 777 and all files to 666. This is terrible advice. Roughly translated it means "I don't understand Unix file permissions well enough to help you, but doing this will hide the problem for now, and I'll be long gone when this terrible advice I'm giving you lets hackers completely overwrite your site."
Our system security is designed primarily to protect sites from each other; it does not (and cannot) protect sites from themselves. So while "writeable everything" may appear to work initially and it seems easy, sooner or later a flaw will be found in your site's code or in the language it's written in — especially if that language is PHP. At that point, if your site is full of writeable files and directories, hackers will make short work of it. When deciding what to make writeable, please keep in mind the old adage, "If you don't have time to do it right, when will you have time to do it over?"
We strongly discourage members from making script files and key directories (like /home/public) writeable by the web user. This setting is used by some applications to enable self-updating over the web. We discourage that practice as well; if you can update your site over the web, so can someone else, and the site may look very different when they finish with it. We recommend using out-of-band methods to update site applications. For example, we support and recommend the use of the WP-CLI command line tool to keep WordPress installations up-to-date without exposing them to massive compromise resulting from the frequent security problems WordPress is so famous for.
Therefore, the final rule of thumb for writing files is not to set anything to be writeable over the web unless you don't mind restoring it from backup after hackers get to it. We hope this encourages you to both be conservative in what you allow your application to write, and to keep good backups. 😀
We support CGI scripts with a .cgi extension in any directory in any of the available CGI languages. You do not need to limit your scripts to a cgi-bin directory, but you may if you wish (they will still need a .cgi extension unless you use the SetHandler directive in your .htaccess file). If you have trouble getting your scripts to execute make sure they are uploaded with execute permissions, that the #! line is correct, and that you've used Unix-format line endings.
CGI applications may be automatically terminated if they consume excessive system resources, run for an excessively long time, or appear to operating as "daemon" style processes.
NOTE: In addition to .cgi the following "default" CGI extensions will also work: .py .pl .rb
We allow the setup of scheduled tasks that run on a regular schedule, as often as once every ten minutes. This feature is available as "Manage Scheduled Tasks" in the "Actions" box on the Site Information page.
This feature is supported for all server types including static sites and can run tasks either as the site owner or the web user.
Output from the scheduled task (stdout and stderr), if any, will be delivered by email if possible. If there is no output, no email will be sent. If your email address is bouncing or refusing messages, or if the output is extremely large, it will be diverted to a file in your site's /home/logs directory.
For tasks that need to run more frequently, you should consider a daemon process instead.
You can place customized PHP configuration directives in the file /home/conf/php.ini. This file does not exist by default; create it if you need it. Give the file 644 permissions, so it is readable but not writable by the webserver.
PHP will process this file after, not instead of, the system php.ini file, so you only need your site-specific changes.
This file is not parsed on every request. Changes take a few minutes of idle time to take effect. If your site is never idle, changes may never take effect. To help it along, you can run nfsn web-kick from the command line on the ssh server to force the reconfiguration. Alternatively, you can place your site in maintenance mode for a minute from the Site Information panel in our member interface.
Use the phpinfo() function to review the active config and confirm that your changes have taken effect.
Examples:
Change PHP settings:
upload_max_filesize = "20M" display_errors = Off log_errors = On
Enable PHP extensions that we provide but do not enable by default:
extension = "imagick.so" extension = "mongodb.so"
Load custom PHP extensions that you have built yourself:
You may include any directive supported by the version of PHP you are using in this file. For more information about PHP configuration directives, see the official PHP documentation.
To make sure you stay pointed at the right location, use the PHP-standard $_SERVER['DOCUMENT_ROOT'] value to refer to your site's public directory.
We also provide the $_SERVER['NFSN_SITE_ROOT'] variable for this purpose, in addition to DOCUMENT_ROOT. NFSN_SITE_ROOT points to your site's root directory, the parent of public and protected, making it the best choice for safely referring to the protected directory from PHP.
We strongly recommend that you use $_SERVER['DOCUMENT_ROOT'] or $_SERVER['NFSN_SITE_ROOT'] whenever possible and avoid hardcoding paths in order to avoid problems in the event of a change.
The best one is the one that works best for you. HTML editors vary widely in terms of features, methodology, and target audience. There is no way to recommend a single best tool for everyone. If the program gets the results you want and you understand how to use it, then it is right for you.
Some factors to consider in choosing a program are:
Does it provide the ability to easily preview your site? (Don't take this for granted; some tools make this surprisingly difficult.)
Does it offer the option to publish your pages for you via SFTP or rsync, or will you need an external program for that?
If you want to use PHP or other dynamic content on your site, will the program make that easier or harder?
Do you like and understand how the program works?
While we still use vim every day, as of 2024, our own websites are largely maintained using the JetBrains IDEs. We can enthusiastically recommend them for complex dynamic sites, and they also provide some support for editing HTML, but they have drawbacks. They aren't for site design or layout, they carry a substantial learning curve, and they're not exactly cheap. So they aren't the best choice for every situation. Visual Studio Code is free, high quality, and seems to be very popular, but also emphasizes programming over page design.
PHP's default memory_limit is -1 on our system, which disables its built-in memory limit.
Although you can change this, any other value will only decrease the amount of memory available to PHP. Consequently, we recommend against setting it in almost all situations.
Regardless of this setting, system ulimits on memory allocation will continue to apply and are not user-configurable.
For a tutorial/HOWTO approach, we like the w3schools.com site in particular, because it gives you the ability to fiddle with their examples and see the results in real time. They have guides for HTML, CSS, JavaScript and PHP, among others.
The World Wide Web Consortium (W3C) defines many web standards, and they have information about HTML and CSS. The standards documents can be a bit dry, but they are the definitive final word on the subject.
No. By default, this feature of PHP is not enabled. It is widely considered a serious security risk and we have seen a number of member sites victimized by exploits related to having register_globals enabled. We discourage its use.
However, if you understand the implications of register_globals and you are prepared to accept the increased security risks associated with its use, we have provided you with the means to enable it on a per-directory basis. Simply create an .htaccess file in your public folder containing the line:
php_flag register_globals on
You can verify that this is working by using the phpinfo() function on a PHP page. You should see register_globals set to "On" in the local context and "Off" in the global context.
If you do not need register_globals support, you do not need to take any steps to protect your site from exploits related to it.
The path to the root of your site is always seen as /home by CGI scripts, by modern (5.4+) PHP, by any daemon processes you run, and by you via ssh access.
This is reflected in the NFSN_SITE_ROOT environment variable, which will always be set to /home for CGI scripts.
Select the name of the site you want to change in the "Short Name" column to go to the Site Information panel for that site.
On the Site Information panel, select the "Edit" button on the "PHP Version" line of the "Config Information" box.
On the "Site PHP Version" panel, select the version of PHP you want to use and press the "Save Changes" button.
Note: If you do not see a "PHP Version" line in your site's Config Information box, your site's selected server type may be out of date, or may not support PHP at all. To resolve this, you can change your site's server type.
By default, CGI scripts are executed as the "web" user and group, which has almost no privileges on our system. In most cases, this is the best choice, as it controls the damage that a vulnerable script can inflict. However, for some file-management and other applications, it is necessary for a script to run with the full permissions of the user that owns your files (i.e. you, a.k.a. the "me" user ID when viewed from ssh).
To this end, we allow you to set the suid and/or sgid file permission bits on CGI applications. When the suid bit is set, the web server will execute the script using the user id of the owner of the script (provided that the owner of the script is you). When the sgid bit is set, the web server will execute the script using the group id of the group that owns the script. It is safe to use the suid/sgid bits for this purpose; our system does not otherwise honor them.
Please note that there are security implications to running web scripts as your own user ID. If such a script is compromised, you will need to delete your entire site and recreate it from scratch or otherwise manually check every single file because there will be no other way to ensure that other files have not been subtly changed. For this reason, we strongly discourage the indiscriminate use of this feature as a substitute for properly setting up file permissions.
You may be able to use our ssh environment to compile your application for our servers; we provide C & C++ compilers for this purpose. However, we only provide these tools as-is; you are completely on your own with respect to using them or getting custom CGI applications to run on our servers.
By default, most files and directories are not writable by the web server. This is an important security precaution, as this prevents minor (and, sadly, common) security flaws in tools like PHP from turning into catastrophic site-wide destruction.
Consequently, the first step is to determine whether you should make a given file or directory writeable by the web server (e.g. from PHP or a CGI script). Here is our official recommendation on that subject:
No file should ever be both modifiable over the web and executable over the web.
For example, no PHP file or CGI script should ever be web-writeable. Writeable content should be minimized and limited to static items like graphics.
Once you have determined that it's appropriate to make something writeable, the specific requirements differ depending on whether you are modifying an existing file or creating a new one:
To create and write to a new file, the parent directory must be writable by the web server.
To write to an existing file, that file must be writable by the web server.
(Files created by the web server will generally be writeable by the web server by default.)
The web server runs as the "web" user and is in (only) the "web" group. Each site also has its own private user and group unique to that site. When you create a file, it will go into the site's private user and group. As a result, there are three ways to mark a file or directory as writeable by the web server.
You can leave the user and group ownership as-is and grant the "other" user (i.e. the web server) write permissions with a command like: chmod o+w example.txt
You can set the group ownership to "web" with a command like chgrp web example.txt and then grant that group write permissions with a command like chmod g+w example.txt
If the web server creates the file or directory, it will be owned by the "web" user and will usually have "user" write permissions by default. (The equivalent of chmod u+w example.txt.)
So, setting files or directories to be writable by the web server is a two step process:
Check the user and group ownership of the file and/or parent directory (usually shown by SFTP/FTP clients or the ls -l shell command) to determine whether the web server will be treated as user, group, or other when accessing it.
Make sure that the appropriate user, group, or other write permission is set via chmod on the command line or the equivalent function in your SFTP/FTP tool.
Usually people have trouble getting the web server to write files, but the reverse problem is also possible: when the web server creates files, it is possible for it to set them such that you can't access (or delete) them. If this happens, you can repossess the offending files. To prevent it from happening in the first place, make sure your scripts use an appropriate umask, such as 002. This will cause files and directories to be created with read and write permissions for the web group, which you are in, so you will retain access to them.
Many types of sites have a directory for user-uploaded content. Graphics related to posted articles, or avatar images for users, etc. Securing these can be very tricky. We recommend dividing this process into two steps.
First step: Your code should limit what types of files to upload. For example, if you are uploading forum avatars, it might be appropriate to allow jpg, png, and gif files. If you are working on a project team website for school, you might be uploading a lot of .pptx or .pdf files.
Watch out for multiple file extensions! It's not enough to just check if the file has ".jpg" in it, because it might be named "exploit.jpg.php" or "exploit.php.jpg." Apache parses file extensions individually, so both of those examples will be executed as PHP. (Although exploit files are only rarely so helpful as to have "exploit" in the name!)
If you're using application software, like WordPress, it may take care of this first step for you. If not, you'll have to code it yourself. Here is a PHP starting point. (And here is the unit test for that starting point.)
Second step: You should place an .htaccess file in any web-writeable directory that will prevent execution of files that slip past or that get onto the site through some other vulnerability. Create or add to that directory's .htaccess file with something like this:
<FilesMatch "\.(cgi|php|pl|py|rb)">
Require all denied
</FilesMatch>
This is hardly infallible, but will foil many hacking attempts, and should be included in any directory that contains uploaded or cached content. Depending on your site, you may want to add html, js, and css to the list of prohibited extensions.
To reverse this restriction for a subdirectory (rarely needed and even more rarely a good idea), create or add to that subdirectory's .htaccess file with content like:
<FilesMatch "\.php">
Require all granted
</FilesMatch>
In the case of adding blocking execution in a directory, always block everything. In the case of re-allowing execution in a subdirectory, allow only the specific type of execution you need. The above example re-allows PHP.
These steps cannot guarantee that your site's upload directory can't be exploited, but they will protect it from most of the generic bulk attacks that are designed to exploit known vulnerabilities on sites with a default configuration.
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.
If you encounter a problem, we want to help. To do that, we need information.
When requesting help, please answer all these questions:
What exact service or services we provide are involved?
What were you (or someone else) attempting to do when the problem occurred?
What results did you expect?
What were the actual results, including any error messages?
How do the actual results differ from your expectations?
When did the problem (begin to) occur?
Be clear, complete and as specific as possible. All of these questions have simple, obvious, useless answers. Avoid them; they won't help solve your problem. Make the problem obvious with answers that lay it out for someone who isn't you to understand.
If we don't have all this information, then our initial response will probably be limited to requesting it (often by sending you a link to this FAQ entry) so we can help you.
Details on each item above:
Name each site (including a specific URL if applicable), domain, database, service, functionality, or email address you're having a problem with and how it pertains to us. E.g. "The site example which is hosted here."
A description of what happens (or happened). This may or may not be specific to you. E.g. "I was trying to upload images to the 'content' directory of the example site with SFTP." Or "All visitors to https://www.example.com/some/page started getting an error."
Be as specific as you can; it's important. E.g. "I expected the files I uploaded to appear on the site" might suggest a very different problem than "I expected to connect to the SFTP server."
Describe the problem. Never omit or paraphrase error messages. They are crucial diagnostics. Many of the error messages produced by our system are customized to include specific explanations or lists of things to check when they occur. Paraphrasing or omitting an error may hide an easy and immediate solution. Copy and paste text if you can, but take screen shots if you have to. Include anything else that provides context: output messages, configuration data, log entries, etc.
Provide a simple test an idiot could perform to tell the difference.* E.g. "The error page says 'Error' in small black letters and the correct page says 'Example.Com 24x7 Internet Plumbing: We flush the tubes!' across the top in blue."
Be as precise as possible about times, and always include the time zone. (Good: "about 7pm Eastern last night," better: "at 7:13pm Eastern last night," best: "2020-10-01 11:13:41 UTC.") If a problem reoccurs continuously, state whether you're giving the time when it first occurred or, if you don't know, when you first detected it. If the problem is intermittent, please also provide a list of times, the more recent the better. If this is covered by timestamps in log files you're providing, that's perfect.
Other general tips:
If you're asking about an error on your site, make sure you have your site's error log enabled. Then check it. There is a good chance that it will tell you exactly what the problem is.
Use the "Troubleshoot Site" action on the Site Information panel for sites we host. It can identify a lot of weird domain and DNS related issues related to sites hosted here, so it'll help us to know if you've tried that and what the result was.
If you think the problem is something we need to fix, outline the evidence supporting that. We control only a small portion of the Internet; ISPs control part, backbone carriers control others, and you control the stuff on your end. Making it clear why you think the weak link is in our portion of the chain
saves time and identifies your issue as one we need to act directly on.
Describe anything you've already done to troubleshoot the problem, and what the result was. This will also help clarify the problem, and will help you get faster help, because people won't have to retrace your steps.
*If you guessed that by "idiot" we meant "computer," you win 50 Internet points.**
As a security precaution, CGI and PHP scripts run with different user credentials than you do when you edit your files. Although the CGI/PHP user has significantly fewer privileges overall, it is possible to create a situation where an application creates files or directories that you do not have permission to access or remove via FTP or ssh. This typically happens if an application's umask is set incorrectly; the resulting files or directories will be owned by the "web" user and will not be group or world writable. (Correct umasks are 0 or 002, depending on the expected group ownership. A umask of 0 should work for most web applications, and does not compromise security on our system the way it does on some shared hosts.)
If you get stuck with web-owned files you can't access or delete, you can regain control using the "Repossess Files" action on the Site Information panel for the affected site. However, if you find yourself doing this on a regular basis, that tends to indicate your site's permissions aren't set properly.
This is a restriction imposed by Apache. It is designed to prohibit ambiguity in determining which access controls apply to the directory.
Assume your public directory contains a subdirectory called example. If you access it via /example, you have not entered that directory. That means that the .htaccess file from your public directory would be applied, but the .htaccess file inside the example directory would not. However, if you access it via /example/, then you have entered the directory and both .htaccess files will be applied.
Now, assume that your public directory's .htaccess file allows all visitors and has directory indexing enabled. Assume that your example directory's .htaccess file allows only visitors with a certain cookie set and denies directory indexing. In this case, if it were allowed, visiting /example would produce a listing of the contents of the example directory while visiting /example/ would produce an access denied error or demand for authentication.
To prevent the confusion and security issues that such conflicting behavior would create, Apache detects attempts to access directories without trailing slashes and automatically issues a redirect to the same URI with the trailing slash appended. That way, you never have to worry about the scenario in the preceding paragraph.
Although you can't stop people from typing one in by hand, make sure you don't use invalid directory URIs internally on your site because they require this extra redirect, thus making your site appear slower.
If you find that these redirects are not using the site alias that you want, for example, if they redirect you to example.nfshost.com instead of www.example.com, then you may need to adjust your site's canonical name settings.
There are a couple of possible explanations for this.
Your site may be configured to do so. WordPress, for example, may default to using the wrong name and needs to be manually informed under the General Settings in the WordPress Admin panel sidebar to use your real domain name. If the General Settings tab is unreachable, you can also change the site name from the command line with the commands:
YourPrompt$ wp option update home https://www.example.com/
You may be entering an
invalid directory URI or something else that causes the network to redirect you. In this case, the server may not be using the name you expect in the redirected URL. (This primarily afflicts sites created prior to April 6, 2008.)
If you have problems of this nature, make sure you have appropriate canonical name settings for your site.
This error (also frequently seen as "503 Service Unavailable" or "The requested website is temporarily not available due to a resource limitation.") means there are too many total simultaneous non-cacheable HTTP requests in progress for your site. This is an extremely rare condition, but the causes, in order of decreasing likelihood, are:
For sites like CMS or blog sites that generate content dynamically, a spammer, email address harvester, or lousy web spider attempts to hit all or a large number of the site's dynamic pages at once. Our system will throw up this error to dissuade the spammer and stop them from dragging the whole server down. In this case, the message will typically only appear for a few seconds to a couple of minutes; as soon as they start getting errors, they usually move on.
This message can also occur if requests for your site content hang or take an inordinately long time to complete. In such cases, they can backlog to the point where the server feels that allowing more of them to build up would just cause a death spiral. (I.e. more requests taking longer causing more requests to take even longer, wash-rinse-repeat until nothing happens at all).
Under exceptionally rare circumstances, this message can indicate that the server that hosts your site is having severe problems. Such conditions are automatically detected and we are notified, so they tend not to persist for very long.
If your site has several hundred simultaneous visitors for sustained periods of time, it's remotely possible to hit this limit even if your connections complete very quickly. In this case, and only in this case, we will raise the limit, because this limit provides your site with important protection against all the other cases.
Please be aware that while almost everyone starts out thinking #4 is the reason that applies to their situation, the cause almost inevitably turns out to be something else. A good rule of thumb is that each possible explanation above is about ten times less likely than the one above it, so the top one is 90% likely and the bottom one is about 0.09% likely.
If this message persists long enough to cause problems, the explanation is most likely the second one. In that case, the way to troubleshoot it is to identify and resolve the cause. Coding problems that can cause this include, but aren't limited to:
unconditional long sleeps
infinite loops
issuing blocking system calls that can hang indefinitely
poorly-optimized MySQL queries
anything that serializes requests (causes them to have to wait in line and get handled one at a time)
doing too much work to process a request -- CPUs are only so fast
making network connections (e.g. DNS or HTTP) to other sites or services that are down or unreachable without a reasonable timeout
Some poorly-written WordPress and Drupal plugins have been known to cause these sorts of problems under heavy loads, particularly ones that deal with statistics or running periodic scheduled tasks.
If you have a subscription membership and open a support issuewhile the problem is occurring, we can typically identify the problem URLs for you, and may be able to give you some insight as to what they are waiting for. After the fact, it may be possible for you to get some idea of what happened by looking at your site's access logs, if they were enabled.
Please keep in mind that this limit is not some nuisance we put in at random to cause problems for our members. It is a crucial protection that keeps your site (and others') safe and available. When someone says they want it removed, we hear: "My car would go a lot faster through the mountains if it didn't skid along the guardrail every time I go around those hairpin curves! Take that guardrail out!" We know from experience that if we take out the guardrails, the car won't go faster; it will fly off the side of the mountain and end in a fiery crash. You may be willing to take that risk with your site, but since ours is a shared hosting service, we can't risk letting you take others down with you. If you want the limit raised, be prepared to show us ample concrete evidence documenting both your sustained high traffic levels and the excellent performance of your highly-optimized code.
Try the "Troubleshoot Site" action on the Site Information panel. It is pretty good at detecting site problems, DNS misconfiguration, and domain registration errors.
If that doesn't work, you haven't changed anything that may have caused this, and there is nothing listed in the announcements about something wrong right now, please contact support and provide as much information as possible about your problem. Be sure to include the name of the site you are reporting trouble with!
First, we always recommend that attack-prone sites minimize their attack profile by consciously examining the use of large files. One good example of this is using graphics compression to make images smaller, or to evaluate whether that one graphic really needs a 24 megapixel click-to-zoom version.
These steps are primarily useful if your site is attacked by a large number of different addresses, or if the addresses used change rapidly. (It's also a good way to save money and ensure a fast-loading site in the far more common not-being-attacked case, including high-usage periods like getting mentioned on Reddit.)
Second, you can edit your site's IP access controls. This is the most efficient way to block access to your site in that it will have the least performance impact on legitimate visitors. However, our system IP access controls are general purpose and not specifically designed for abuse. Therefore they return a small error message to visitors, and that still takes up some bandwidth; an attacker blocked by our IP access controls would have to hit your site about 820,000 times to use a gigabyte of bandwidth.
If you're sure someone is attempting to waste bandwidth, there is a third option you can use to eliminate as much of the response as you can. Take the following steps:
Create a zero-length file called "no" in your site's public directory. (E.g. touch /home/public/no from the ssh server.) Do not skip this step!
Add the following to your .htaccess file (replace 1.2.3.4 with the IP address to block):
Affected visitors will receive an empty "OK" response. This still includes HTTP headers, but that's all. An attacker blocked by this would have to hit your site about 3,600,000 times to use even one gigabyte of bandwidth.
There is a variant of this that saves slightly more bandwidth and may fool would-be attackers into thinking they have succeeded in taking your site down. However, it carries an additional risk: It bends the HTTP standard, and if you do not set the IP address properly, search engines who see this response will also think your site is gone and remove references to it. The code for .htaccess is (again replacing 1.2.3.4 with the IP address to block):
# Do not put this in your .htaccess unless you have read the warning above.
RewriteEngine on
RewriteCond %{REMOTE_ADDR} 1.2.3.4
RewriteRule .* . [L,G]
ErrorDocument 410 "."
This returns an HTTP "410 Gone" response and one byte of content. This has the side effect of eliminating some HTTP headers. As a result, an attacker blocked by this would have to hit your site about 4,600,000 times to use up a gigabyte of bandwidth.
If you need to block more than one IP address using the latter two techniques, combine them as in the following example:
While the only way to completely protect your site from all Internet attacks is not to put it on the Internet, we hope these options will help you defend yourself in the unlikely event that your site falls victim to a bandwidth-wasting attack.
When asking for help in our forum, we strongly recommend against replacing the name of your site with example or a domain with example.com or taking similar steps to conceal the specifics of what you're asking about.
Obfuscating the details of a question or problem forces people to guess rather than investigate. Guessing is both difficult and inaccurate. When you want other people to help you, it's a good idea to make that as easy as possible. Doing so also makes it more likely that their response will actually help.
It's also frequently the case that when people obfuscate the details of what they're asking about, they inadvertently omit the information needed to resolve their problem or answer their question. This is perfectly normal; it's frequently impossible to know what information is needed to solve a problem without knowing its solution. And if someone already knows the solution to a problem, they usually don't ask for help solving it.
So, when asking for help in the forums, we recommend providing as many specific details as possible, along with following our standard troubleshooting advice. This will almost always help you answer your question or solve your problem faster and more accurately.
If you are uncomfortable posting necessary information in the forum, you may wish to look at our subscription membership which includes an option for private support.
We have no idea. We do not determine whether your address information is correct or not. (We have no way of knowing!)
When you enter your address information, our credit card processor forwards it to your card-issuing bank. Your bank sends us one of three responses:
"Yes, that's correct."
"No, that's not correct."
"We don't support address verification." (Most banks outside the US.)
If our system tells you that the information you entered isn't correct, it's because that's what your bank told us. Your bank does not tell us why it is incorrect nor do they provide the correct information (according to them).
Consequently, any questions you have about why your address was reported as incorrect should be directed to the bank that issued your card, not to us.
Should you find yourself in this situation, you should also be aware that your bank may place a temporary pre-auth hold on the funds, even though the transaction was declined. Also, if you call your bank's customer service, they will see the pre-auth hold. Many bank customer service reps will incorrectly claim that the transaction was approved without looking into it any further.
You may also encounter this issue if you use a US-based bank, but your billing address is outside the US. We have seen several cases where the banks could get the foreign address right on statements, but their address verification system could not cope with it.
If you find yourself in this situation, for whatever reason, you have a couple of options:
Use a credit card issued by a different bank.
Use the same card (or another) to pay through PayPal.
Update your address with your bank, even if it looks correct, then wait 24-48 hours. (This is a bit of a long shot, but it helped some people when their bank's internal systems were out of sync and no one at the bank would admit it.)
The above applies primarily to US-based members and those in other countries with compatible AVS implementations. The UK, for example, uses an entirely different system. For reasons we do not fully understand, certain banks in the UK falsely return that the address (or zip) is incorrect when they should return that they do not support US-style address verification. This error on their part will cause our system to reject your card no matter what you enter for your address details. This affects about 10% of our UK members.
This could happen even if you have successfully used the card online in the past. We are not only unusually strict in address verification enforcement to protect our members and ourselves from fraud, but we are also not large enough to have specialized card processing options for the UK as many huge Internet retailers (e.g., Amazon) do.
Of course, you can try contacting your bank. But bank customer service agents are rarely trained on the intricacies of address verification. (And that goes double if they're in a country that uses a different system.) There's somebody deep in the bowels of the operations department of your bank who understands what's going on, but good luck getting them on the phone; we've never had a report that a member accomplished that.
We are very sorry for the inconvenience caused to the handful of our members who run into these kinds of problems. They affect only a few, and the cause is completely beyond our control, but it's still endlessly frustrating.
This error occurs when a CGI script exits before writing a complete set of HTTP response headers (not even an empty one). It can happen for a variety of reasons:
The script may be dying before it writes any output. This can happen, for example, to perl scripts if they have a dependency that cannot be resolved.
If there is a problem with the hashbang (#!) line of the script. Uploading the script from a Windows machine in binary mode can cause this, or the path to the CGI interpreter you are using could be incorrect, for example attempting to use #!/usr/bin/python instead of #!/usr/local/bin/python.
A compiled application could be missing a shared library dependency. You can use ldd or try running the script from the ssh command line to check shared library dependencies.
There could be a system problem preventing the execution of the script.
In all cases, the best thing to do is make sure your site's error log is enabled and see what it says about the problem. If the error output says that there is a system problem preventing execution of your script, or if there is no message in the error log at all, review your options on the Support tab. Whichever option you choose, please indicate the URL of the script you're having trouble with. In many cases, it will be easier to debug a problem if you can provide a simple example at a publicly available URL.
There are a few incompatibilities between Apache 2.2 and 2.4. These are described in detail in the Apache 2.4 documentation.
In most cases, the source of compatibility problems is an .htaccess file. If it is not compatible with Apache 2.4, it will cause your site to return "500 Internal Server Error."
To narrow down the specific cause, we recommend that you enable your site's error log in the member interface (if you haven't already). Once it is enabled, access the site a few times to exercise the error, and then the error_log file in your site's logs directory should point you directly to the problem.
The most common example comes from using the Order directive to restrict access to certain content. It has been completely removed from Apache 2.4, but is still very common in example files and configs distributed with many web applications that haven't been updated yet.
To update a 2.2 .htaccess file containing something like:
Order deny,allow
Deny from all
the 2.4 equivalent of both lines would be the single line:
Require all denied
to deny all access and:
Require all granted
to allow it.
Other 2.2-specific configuration directives that have changed in 2.4 can be similarly adapted. See the Apache documentation linked above for complete details.
If you get a message similar to the following when accessing your WordPress site's control panel:
The requested URI could not be accessed.
Or, for older versions of PHP:
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
Fatal error: Unknown: Failed opening required '.../wp-login.php' (include_path='...') in Unknown on line 0
this indicates that your WordPress login page has been temporarily disabled to protect your site, your wallet (and us, other sites we host, and the Internet at large) from a hostile attacker trying to force their way into your site.
When this happened, an email was sent to you with the full details, including how to resolve the situation. You should have that email. If you don't, stop and make sure your member contact email address is up to date and that your email system is not marking messages from us as spam.
When you next need to log in to your WordPress site, all you need to do is reset the permissions of your wp-login.php script. The recommended permissions for this script are 0644. This is typically done with a command like:
YourPrompt$ chmod 644 /home/public/wp-login.php
(If your blog is not installed in /home/public, you may have to adjust this.)
You can run this command from the shell or using the "Run Shell Command" action on the Site Information panel for this site in our member interface. Just edit the permissions of the wp-login.php file and make sure that it is readable by everyone.
If you have frequent problems with this, you may wish to investigate the security options presented in the "Stopping Login Attacks" and "General Security" sections of our Advanced WordPress Configuration guide.
This indicates that something unusual happened on that page that the system thinks we need to know about.
We're committed to increasing the quality of our software, so we're constantly implementing new checks and stricter language features. So in almost every case, the "bug" is just the system letting us know that it found something that isn't technically wrong, but could be better. But sometimes, it's a real bug. Either way, we'll be automatically notified, and we'll check it out and fix it.
Most of the time, you can ignore the icon. But if you see one, it's a good indication to double check that everything happened as you expect.
Treat such a request as the world's most misleading "permission denied" error.
When WordPress fails to write to a file due to a permission error, it has some very old code that tries to work around the problem by asking for FTP information. But these days FTP is dangerously insecure and unsupported. Do not provide your NearlyFreeSpeech.NET credentials; it won't work and could potentially get you hacked.
If it happens during a media upload, review the "Enable file uploading" section of our Installing WordPress guide. It will show you how to set your site up with the permissions to make that work.
This also comes up if you attempt to have WordPress update itself over the web. Don't. It requires major security compromises that will turn the next vulnerability discovered in WordPress, PHP, your blog's theme or any active plugin into a complete takeover of your entire site. We will not assist you to do that.
To safely update WordPress and its themes and plugins, use the wp-cli command line tool, as documented in the "Upgrade WordPress" section of the Installing WordPress guide.
The username for SFTP and ssh access is not the same as your member login; it is based on both your member login and the site name. The password, however, is the same as your member password. The specifics are listed in the "SSH/SFTP Information" box on each site's information panel in our member interface.
To find this information:
Visit the Sites panel to display your list of sites.
Select the site's "short name" in the "Sites" table to display the details about the site you want to access.
Find the box titled "SSH/SFTP Information."
Locate the username row and the appropriate hostname row for the protocol you wish to use.
This question depends largely on what tools you are using to create and manage the content of your site. There are four primary approaches people use.
Many web design tools have the built-in ability to upload content directly to our service through a "Publish" option. If you are using such a tool, you can set it up to publish your site via SFTP.
It is also possible to develop content in one tool and then upload it with a separate SFTP program, like WinSCP (for Windows) or Transmit (for Mac). (Linux also has graphical SFTP tools, but they vary widely by distribution and desktop environment.)
Some people prefer to hand-code their site, either directly on our servers via ssh or using a command-line tool like rsync or git to deploy remotely.
A less-common option is to use a tool like ExpanDrive or sshfs to make our web server appear like a local directory, allowing you to use whatever editor, graphical file manager or command line tools you wish to manage your content on our servers from your local computer.
In all cases, you'll need to check the documentation for the program you are using for specific instructions, but at a minimum you will require the connection information for your site to upload successfully.
We do not provide any "built-in" web tools in our member interface for content authoring. Such tools tend to be very limited; they offer only basic functionality and tend to produce a whole lot of nearly identical websites. As such, they do not provide the sophisticated and powerful options expected by our members.
The SSH key fingerprints for our ssh servers are in this FAQ entry.
SFTP and scp are supported. Port forwarding is supported but is only permitted for establishing secure remote connections to your MySQL database.
Important: Our ssh environment is provided solely for maintaining your website and is not to be used for any other purpose. This specifically prohibits using it for proxying, port forwarding, or anything similar. Automated access to the ssh server is likewise prohibited, with an exception allowing connections once per day for the purpose of making offsite backups.
All uploading clients should automatically be in the correct folder after they connect. Do not change your software's default upload directory setting unless you are absolutely sure your client is getting it wrong.
For FTP clients (including publishing programs such as Dreamweaver that upload using FTP), the correct directory is /public.
For ssh and SFTP clients, the correct directory is /home/public.
(Once uploaded, scripts that run on your site will use a different path to access your files, depending on whether they are PHP
or CGI.)
On macOS, OpenSSH is preinstalled. It is accessed by running the ssh command from the Terminal application.
Recent versions of Windows also include OpenSSH. The ssh command can be used from the Command Prompt or PowerShell.
PuTTY is a very popular free graphical ssh client for Windows. It requires no local installation and is a perfect tool to slap on a USB memory stick for secure access from anywhere. Putty also comes bundled with some versions of WinSCP, which is an excellent tool for managing files hosted on our service. PuTTY 0.75 or later is required if you are using RSA keys (not recommended).
Other options also exist, but are substantially less popular:
The far-and-away best graphical ssh application for both Windows and Mac is VanDyke Technologies' Secure CRT. This program is rather expensive ($99) but worth every penny if ssh is a part of your daily life.
Almost all versions of Linux and BSD preinstall OpenSSH or make it available as a package.
Once you have found or installed your ssh program, give it your connection information to get connected to your site hosted on our service. If you are using OpenSSH or a similar tool, the command looks something like:
Graphical tools vary widely; consult their documentation.
Once connected, you will get a shell prompt, which may look something like:
[example /home/public]$
Actual prompts can vary widely but tend to end in $ or %. To reflect these variations, in our documentation, we use:
YourPrompt$ echo "Hello, world!"
to indicate that you should type the command echo "Hello, world!" (but not the YourPrompt$ part) at your shell prompt, whatever it looks like.
Due to the variety of ssh options and the complexity of the Unix shell, the full details of their use are well beyond the scope of a FAQ. Many online tutorials exist, like this one. For a deeper dive, many community colleges offer continuing education classes covering one or both topics.
FTP access can be restricted on a per-member and a per-site basis. These settings are completely independent; both the member accessing a site and the site being accessed must have FTP enabled in order for access to succeed.
This is to allow maximum access control granularity in situations where multiple members share access to multiple sites via our adjunct access feature. For example, if you don't want to allow FTP access to your site, and you want to make sure a member with adjunct access doesn't enable FTP access for themself and overrule you.
To enable FTP access for your membership, visit the Profile page and toggle that setting in the "Details" box.
To enable FTP access for a site, visit the Sites panel and select the site by its short name to view its Site Information page, where you'll see the FTP setting in the "SSH/SFTP Information" box.
SFTP is the Secure File Transfer Protocol. It is sort of a hybrid between FTP and ssh.
You can use SFTP to send files to our service. It's much safer and more private than regular FTP because it encrypts both your password and your file transfers.
Since SFTP piggybacks on the ssh protocol, SFTP is also robust in the face of NAT routers and firewalls, which often cause problems for FTP.
Due to its advantages, SFTP is the recommended method for uploading content to your site.
There are a number of SFTP applications listed in our member wiki. (Note that "Secure FTP," which only supports SSL/TLS-encrypted FTP, will not work for accessing our servers via SFTP.)
Our system does not access your site's filesystem until after you have authenticated yourself. Also, correct authentication depends on both member name and site (since more than one member name may have permission to access a given site and a given member name may be able to access more than one site). Therefore, you cannot place a public key file in your site's filesystem to bypass password authentication.
Instead, we keep a separate keychain for each member. To use an ssh public key, you can add it to your keychain on the profile tab.
Once installed into your membership's keychain, an ssh key will authenticate you for any site you are authorized to access, including your sites and any sites you may have adjunct access to.
Per current best security practices, here are the key types we support:
Ed25519 keys are supported. We strongly recommend the use of Ed25519 keys.
ECDSA keys of 256 and 521 bits (521 recommended) are supported. (Recommended for low-power devices if Ed25519 is not available.)
RSA keys of 2048+ bits (4096+ recommended) not on the Debian weak key blacklist are supported, but not encouraged.
DSA/DSS ("ssh-dss") keys are not supported at all. This is a US government FIPS standard developed by the NSA and intended only for low-security usage. (Read: they are probably not secure.)
If you use an RSA key, you must use a client that supports RFC8332 for SHA-256 (rsa-sha2-256) and SHA-512 (rsa-sha2-512) signatures. As of 2021, our servers no longer accept RSA keys with SHA-1 signatures because they are demonstrably insecure. If you run into that issue, please update your OpenSSH client and/or consider switching to faster, safer Ed25519 keys.
Despite the similar names, SFTP and FTP have absolutely nothing in common. If your FTP hostname is ftp.xxx.nearlyfreespeech.net then the correct hostname for SFTP is sftp.xxx.nearlyfreespeech.net.
Our official answer to any problem with FTP is don't use FTP.
Ever. For anything.
FTP support has been deprecated since 2010. It is an outdated, insecure protocol that does not work very well on the modern Internet. We will not provide any support for any problems you have while using it.
If you insist on using it anyway against our advice, you're on your own. Here are some historical notes about FTP that may (or may not) help:
FTP is disabled by default and must be enabled in two places to have even a chance of working.
The username and password are the same as SSH but the hostname is (for all sites) is ftp.nearlyfreespeech.net.
NAT devices (especially cheap residential gateway routers) can process FTP connections incorrectly, and some personal firewall software blocks FTP access. These problems generally manifest as timeouts or reset connections.
If you are able to connect to the FTP server, but attempts to upload or download hang, then switch your FTP client from active mode to passive mode, or vice versa.
Easy way: You can use xyz1.nfsnssh.com instead of ssh.xyz1.nearlyfreespeech.net if you prefer.
Better way: OpenSSH allows the creation of nicknames. To use this feature, create (or edit) the file ~/.ssh/config (on the client machine you will be connecting from, not ours!) and add content like this:
Host nfsnssh
Hostname ssh.xyz1.nearlyfreespeech.net
Port 22
With this done, you can use "nfsnssh" as if it were a hostname in ssh, scp, and sftp. For example, just use ssh mylogin_mysite@nfsnssh to connect to mysite as mylogin.
You can even use the User option to create per-site nicknames to make commands even shorter:
Host *_nfsn
Hostname ssh.xyz1.nearlyfreespeech.net
Port 22
Host mysite_nfsn
User mylogin_mysite
Host othersite_nfsn
User mylogin_othersite
Then you just ssh mysite_nfsn to connect to mysite and ssh othersite_nfsn to connect to othersite. It doesn't get much shorter than that! See the ssh_config man page for complete details.
If you don't happen to be using OpenSSH, many other ssh tools offer similar options, many with graphical interfaces that make establishing a connection as simple as clicking, regardless of the hostname.
The first thing to check is to make sure you are using the correct connection information for your site, including your username and password as well as the correct name of the server for the service you are trying to use. You should always check this, even if you are sure it is correct, before exploring more exotic options.
If you are unable to connect at all, or if the connection appears to drop immediately, one possible explanation for this is that you are running firewall software (or have a hardware firewall) that is blocking your connection.
If you use file sharing software, many "P2P block list" applications can block connections to us.
In such cases you will need to either disable the application or set up a manual override to allow the connection.
The most common diagnostics that indicate problems with firewalls and blocking software are "Permission Denied," "No route to host," "Connection refused," "Host unreachable," or "General failure" when attempting to access our FTP or ssh servers, but no similar problem when trying to access your site(s) or ours by HTTP or HTTPS. If you can't access anything at all, the problem is likely something else.
This can also happen if you have non-functional IPv6 connectivity. Our ssh server supports IPv6 and some home network devices advertise IPv6 capability even if it is not supported by your ISP.
No. Automated FTP access is never allowed. (And the use of FTP at all is strongly discouraged.)
If automated FTP accesses are detected, the affected site's FTP access may be automatically disabled. If the problem reoccurs, we will block it entirely.
Embedded devices that upload information via FTP automatically such as webcams and weather stations are strictly prohibited. They are a security disaster; they broadcast your plaintext member password over the Internet every time they connect.
If you need FTP access for allowable purposes, but your FTP access to one of your sites has been blocked due to repeated or egregious violation of our policies in this area, and you are a subscription member, you can contact our support for assistance. If you are not a subscription member and you have FTP access blocked under this policy, you will have to alter your methodology to use SSH/SFTP (which you should be doing anyway) and to comply fully with the policies outlined above.
Any automated SSH/SFTP access must use a public key. No hardcoded passwords!
As long as you are physically initiating uploads or downloads yourself you're fine, even if an automated component is involved. (Just make sure you're either using a key or typing the password by hand.)
Unattended or automated SSH/SFTP access is allowed only for these purposes:
Purpose: To make your own offsite backups of content hosted here.
Frequency: Up to once per day per site or MySQL process.
Purpose: To upload content.
Frequency: Less often than whichever of these is more permissive:
the average ssh-based upload frequency is less than the average web-based download frequency (in other words, people are viewing the content at least as often as it is being updated)
an average rate of one file per five minutes
If you want automatic unattended uploads beyond these limits, you should use HTTP POST or PUT requests and a small script on your site to receive the files.
Please respect the shared resources used by SSH—which we currently do not charge for—by observing these guidelines. If you have any questions about what is allowable, please ask.
(This answer is for SSH and SFTP. Automated FTP access is never allowed.)
