Frequently Asked Questions
Adjunct membership 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 information about the site in our member interface, but 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:
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 are adjunct members on 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 members have 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 the site from our system, close your accounts, see your balances, or perform any other activity not related to site content.
You are solely responsible for providing any support needed by adjunct members who do not have their own account and support subscription with us.
Adjunct 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:
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.
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:
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 2 kilobyte (KiB) disk blocks they utilize. These 2 KiB 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.
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.
Each site has a home directory that lives somewhere on our network, called the site root. Inside the site root, there are several subdirectories:
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.
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.
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.
TLS is supported by default for the .nfshost.com name for all newly-created sites (e.g. example.nfshost.com), and can be enabled for older sites from the Site Information panel for that site in our member interface.
For custom aliases, such as www.example.com, you will need a key, a certificate, and (usually) a certificate chain. If you have these already, you can install them through the shell or the member interface, whichever you prefer.
If you don't already have a certificate provider, the most popular option is Let's Encrypt, a free service. The easiest way to use Let's Encrypt certificates is to type the following command in the shell:
In most cases, that will set up everything related to TLS for your site using Let's Encrypt certificates, including automatic renewal.
This script handles the simplest, most common cases. If your site uses custom web daemons or custom access controls, the automatic scripts may not work for you. For such cases, we provide the dehydrated ACME client; it provides hooks to install and clean up challenges that you can use to interface with whatever you're doing.
If you would rather have us take care of everything, we can also provide managed installation of Comodo PositiveSSL DV certificates for a small fee.
As long as an account balance is positive, you may create and manage as many assets (web sites, domains, databases, etc) as you like funded by that account.
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 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.
Within your one membership, you may have multiple accounts (each of which represents "a discrete pool of money") if you wish. We do not ever require you to have more than one account.
The ability to create additional accounts does not have any technical effect in our system. It is solely a convenience feature for you that allows you to differentiate ownership of funds and assets, help track/control your spending, and share things when there are multiple people involved in a project.
Often, this is done for tax, business, or legal purposes, such as to keep business and personal sites separate, or to segregate expenses if you need to manage sites or domains for clients, organizations, etc. It can also be useful if you have one site that is very active or given to surges and another site that must remain available at all times. 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.
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 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 must transfer 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 probably have a registered domain with RespectMyPrivacy service. That is the only service intentionally allowed to overdraft your account. We could very easily cancel or disable it as soon as you run out of funds, but the consequences of doing so are permanent -- once your information becomes public, reactivating privacy later won't cause people to unsee it or remove it from websites that troll whois info looking for and publishing these kinds of changes.
So, because we care about your privacy and we know that oversights happen, we choose to give you every opportunity to correct the problem before we have to expose your personal details. Our policy is to cancel your RespectMyPrivacy service after 30 days of nonpayment. However, during that time, charges will continue to accrue, leaving you with a negative balance. That negative balance directly reflects that we would rather lose money than let a brief lapse compromise your privacy. Also, please keep in mind that privacy service is still needed for about 75 days after the domain expires.
The best way to resolve this is to add funds. If you don't want to do that, you can also remove RespectMyPrivacy to prevent further charges from accumulating, but the negative balance will hang around (and generate reminder emails) until you resolve it or close your membership.
The best way to avoid this is to prepay your RespectMyPrivacy service. You'll even get a 10% prepayment discount for doing so. This option is so good that it's now baked right into the service, but it's not retroactive so if you have an existing domain without it, the change won't take effect for existing domains until you renew them or manually prepay. If you are reading this because non-prepaid privacy resulted in an overdrawn account, that's an indicator that manually prepaying is probably right for you.
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.
The rest of our service is fully paid in advance; charges (and services) automatically suspend when your account runs out of funds. In some rare cases, you can wind up with a negative balance of a penny or two if your usage is just right at the moment your account is depleted. If that happens and you don't want to add additional funds, don't worry, when you cancel our system will scratch out those types of small negative balances.
Naturally, issuing chargebacks can also result in a significant negative balance. Any chargeback-related negative balances must be resolved before you can cancel or access any services paid for by the charged-back funds. (For example, chargebacks are one of the few justifications ICANN allows for a registrar to suspend or seize a domain name.)
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.
As NearlyFreeSpeech.NET memberships are held by individuals and may not be shared or transferred, the only circumstances under which a name can be changed is if you have changed your legal name. (The name shown on the government-issued photo ID you would use to regain access if you ever got locked out.) 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. (And 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.)
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.
You can change your login name at any time for a small fee (waived for subscription members) through the same assistance request.
MySQL process names (DSN's) and site names can only be changed by deleting the existing process or site and creating a new one.
We use your PayPal email address to match your PayPal deposit to your user account. If the email address does not match your contact address, we have to assume that the deposit came from someone else. Since our Terms and Conditions of Service do not allow our service to be used to transfer money from one person to another, we have to regard such deposits as nonrefundable.
If you receive this message because you used an alternate email address, but you are the one who made the deposit from your own PayPal account, you may safely disregard it. This only ever becomes an issue if you request a refund. If your account was funded by a "nonrefundable" PayPal deposit, we'll review it. We're typically able to return a balance remaining from a PayPal deposit to the address it came from.
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 advanced 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 web site) 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. For that reason, don't assume the (in)ability to ping your site reflects on whether or not it is working properly.
Some traceroute applications, like most under Unix, use UDP packets to probe network hops. These applications will show a "filter prohibited" response (usually "!X") 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 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.
For an accurate measure of 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 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.
Follow these steps:
We're delighted to have people refer us to their friends. In fact, we absolutely depend upon it for growth because we spend our money on servers and programming rather than advertising. 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 membership 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.
If you want to secure your site with a certificate that you obtained from a third party for one or more aliases of your site (like example.com and/or www.example.com), that's very straightforward. You will typically need three things, each in PEM format:
First, you can set it up from our website. To do that:
Alternatively, you can set it up from the command line. To do that:
In either case, you will see the results of processing the files you submit, and if the processing is successful, it will take effect within about 5 minutes. Applying TLS files is done on a per-alias basis, so if you have multiple aliases secured by different certificates, that is no problem and they will not overwrite each other.
It's also fine if you include extra intermediate certificates or put things in the wrong order; unlike humans, our system can read the files, and will do its best to figure it out for you and assemble (only) the proper ones in the proper order to get things working.
If you need to generate a key and CSR to get a certificate from a third-party certificate authority, you can do that from the command line:
The first thing to notice about our handling of DMCA notices and the notification-and-takedown process, is our consistent use of the term "allegedly infringing." Receiving a DMCA takedown notice does not mean you have done anything wrong, or even that you have infringed someone's copyright. It only means that someone has claimed (alleged) that you infringed their copyright.
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 are asserting to us 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, and on the other we have some random person we've never met who has no relationship with us making a claim that it isn't. Our first inclination, under those circumstances, is obviously to believe the person we know and trust, which is 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 the way the DMCA takedown process works. Our judgment and opinion don't really 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, the law requires us to go through the notice-and-takedown process, even if the notification looks like complete bunk 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 really 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:
If you do not intend to submit a counter-notification, you may wish to include sufficient supporting justification for us to form an informed opinion on whether to hold this incident against you if future allegations arise, as repeated infringement is grounds for adverse termination of your service.
If you don't respond, or if you indicate that you intend to file a counter-notification and then don't do it, we will assume you are accepting the allegation of infringement. If you don't file the counter-notification, the process ends. Thus, 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:
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.
Pursuant to the law, we will 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 10 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 then to 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 strongly urge everyone not to be bullied or to allow the DMCA process to be abused, we strongly urge you to consult a legal professional if you find yourself in this situation, because the consequences of filing a spurious counter-notification can be significant.
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.
Sites, domains and MySQL processes can be moved from one account to another on your membership using the Change Site Accounts, Change Domain Accounts and Change MySQL Accounts actions found on the Sites, Domains and MySQL tabs, respectively.
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.
If you enter your card billing address (as determined by your bank, not by us) or card verification code incorrectly, we may not be able to accept the transaction. However, the bank that issued your card may place a "preauthorization 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.
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.
We provide two separate sharing options that are very different in terms of power and scope.
The less powerful option is adjunct membership. 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 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.
If you want to stay up-to-date without logging in, minor updates and timely information about outages can also be found on our Twitter feed. (If you don't like Twitter, this information is mirrored on our site with more history than the other options offer.)
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 have any adjunct users, they are listed on the Site Information page for your site.
Visit the Accounts panel and then select "Transfer Funds Between Accounts" from the "Actions" box.
First, we will present the process in brief, as it is very easy and straightforward. After that, we will go into a little bit of detail about why it works the way it does.
That's it. The whole process usually takes about five minutes of your time to arrange.
It's very 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 that the person is involved with. (For the sake of simplicity we'll call people who do this "webmasters" and we'll call the third party the "client" for the rest of this FAQ entry.)
That's a good match for the way our service is set up, and it's fine to do as long as everyone involved understands that, as far as we're concerned, the member managing the account is calling the shots.
From time to time, for various reasons, it becomes necessary to change the responsible party. Maybe a client/designer relationship is ending, or maybe someone is leaving the company or graduating out of 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 webmaster'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:
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 cannot access your membership either. So giving them the 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 absolutely 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 of what our rules and policies are, or how to use our service.
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 personally went through the signup process, 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 completely avoid it: 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.
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.
If (and only if) you are using our secondary DNS service, one of the following name servers may also apply:
It's very important to keep your contact email address up to date. To change your contact email address:
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. Any RespectMyPrivacy domains you have will also be updated to forward correspondence to this address.
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.
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.
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.
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.
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.
The process for sending funds to another member is very straightforward and, unlike other transfers, does not require our intervention.
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 so many non-production sites that you're running into this limit, you may want to consider consolidating them using tools like per-alias document root.)
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):
Sites that people tend to regard as production include (but aren't limited to):
Sites that people tend to regard as critical include (but aren't limited to):
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.
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.
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:
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.
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 membership.
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.
To use account sharing, each person must have their own membership, which provides them with their own personal username and password. (Remember: accounts and memberships are different, and you can have multiple accounts, but not multiple memberships).
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.
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.
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.)