Significant pricing updates are coming soon

I’ve started and stopped writing a bunch of posts over the past few weeks. Recent events have really crystallized some issues that we’ve been looking at for over a year. Those posts are largely ideological in nature, and they tend to ramble on at very great length.

This isn’t intended to be such a post.

This is a post to acknowledge that our service has a couple of serious issues that require more urgent attention.

  1. The cost and threat of DDOS attacks is escalating so quickly that unless we act, they will drive us out of business.
  2. It’s time for us to move toward ICANN accreditation.

Addressing these concerns will require some major shifts in our pricing model. To be completely honest and upfront, these changes will primarily affect those sites and members that are currently paying the least. After the changes, the prices at the low end will still be low, but not as low, and in some cases, lower-cost sites may have a different set of options than they have in the past.

Summary of changes

Here’s a short summary of the changes we are making:

  • We are eliminating the current static/dynamic site distinction in favor of three tiers (effective November 1st for new sites, December 1st for existing sites):
    • Non-production site ($0.01/day) – Static and dynamic functionality, limited realm selection, limited # per membership, might be automatically opted in to some betas, not for production usage or revenue-generating sites;
    • Production site ($0.05/day) – The “standard” option. Full set of realms, unlimited quantity, no automatic beta opt-ins, usable for production or revenue-generating sites; and
    • Critical site ($0.50/day) – An option unlike anything we’ve (publicly) offered before with 24×7 custom monitoring.
  • Bandwidth charges will largely be eliminated (not officially, but in practice, no one will pay them). (Effective November 1st for new sites, on or before December 1st for existing sites.)
  • Resource (CPU/RAM) charges will decrease over 60%, from 17.22 RAUS/penny to 44.64 RAUS/penny.
    (Effective November 1st for all sites that use resource billing.)
  • Domain registrations will increase by $1.00/year. (Effective October 1st.)
  • We will be adding a significant fee to certain violations of our Terms & Conditions of Service that are extremely rare but cause significant hassle for us. (Effective immediately, with a limited amnesty period until December 1st.)

Below, we’ll discuss why we need these changes and then go through them in detail.

About DDOS attacks & bandwidth

Defending against DDOS attacks is very difficult and very expensive. The first key step to fight them off is being able to absorb the inbound traffic they generate. That takes massive amounts of bandwidth. And although already massive, the amount needed is constantly increasing. Right now, we have enough bandwidth to cope with about 70% of the attacks we encounter. That 70%, of course, starts from the bottom. And the success rate is falling. Larger attacks can knock our entire service offline, at least for a little while.

Unfortunately, this is an area where “pay for what you use” simply no longer works. We charge for bandwidth based on outbound traffic from member sites. But we pay for vastly more bandwidth than that to deal with attacks, and we need more still.

Worse, the equipment needed to mitigate DDOS attacks at wire speeds of 40Gbps and 100Gbps is pick-your-jaw-up expensive compared to 10Gbps gear (or, really, anything else we currently use), and it needs both costly maintenance agreements to stay up to date with evolving attack techniques and well-paid professionals to keep it all working.

So what we currently charge is not covering what we currently pay, much less the additional costs it would take to get the success rate up to 85-95% and keep it there as attacks increase in frequency and scale. That’s got to change. We need to increase our revenue, not just enough to cover our current costs, but to cover the additional costs of the bandwidth, equipment, and people necessary to make sure our service is secure, protected, and reliable, now and in the future. That entails charging everyone more.

Most people’s first reaction to that is, “Well, I’m not getting attacked, why should I have to pay more?” Here’s why: most of the sites affected by any given DDOS attack are not the site being targeted. That’s getting worse. We’re seeing more and more attacks on infrastructure, rather than hosting IPs. In such attacks, collateral damage is the whole point. Those typically affect everyone, and are often much harder to deal with. When your site is negatively affected by a DDOS attack on someone else, these are the resources we need to have even a chance of doing something about it.

Even if an attack targets a specific site we host, attacks are frequently non-specific enough that we never figure out who it is. But in those cases where a specific site is being targeted and we know which site it is, does it matter? Sometimes it’s easy to argue that the site operator must have done something to provoke an attack. And sometimes that’s even true. But it’s frequently not. In the longest and most debilitating attack we’ve ever experienced where we identified the target, that target was a small site about a video game. Did that site “deserve it?” How about the website for the orphanage using the same IP address? Should we just wash our hands of it and tell that person, “Sorry, you have to go elsewhere, video games are way too controversial for us to handle?”

Even if we do know the target of the attack, and it’s not just “us,” it’s not like we can send that member a bill. I mean, we could, but nobody is going to pay a surprise $10,000 bill from a service that claims that you’ll never be on the hook for more than the amount of money you decide in advance to put in.

“Who should have to pay for protection from DDOS attacks?” is a trick question. No one should. Period. Because DDOS attacks shouldn’t happen. They definitely shouldn’t be several orders of magnitude easier and cheaper to launch than they are to defend against. But “should” and “is” are miles apart, and we have to take the world as it is, not as it should be. So who does have to pay for protection from DDOS attacks? Everyone.

Protection isn’t optional. There’s no point in offering our service if the minute anyone calls our bluff we have to fold. We’ll never be able to provide every site protection against every attack. There are other — much more expensive — services like Cloudflare’s $200/month “Business” plan that can help sites worried about the last few % of attacks we can’t hope to mitigate. But we can do a lot better than this, and we must do better than this. Free speech, it turns out, is heinously expensive, and the cost is rising rapidly.

Hence, we’re changing our pricing to reflect that all sites, regardless of size or activity, must contribute toward the collective cost of protection from attacks. That wasn’t an easy decision, but we believe it’s the only workable option in the current online climate.

New site types

Non-Production Sites ($0.01/day)

We know that some people who host with us really do need the absolute lowest possible price, and this is it. This is a plan designed to minimize the price by reducing access to some features that are expensive for us, and giving us some flexibility with respect to how we host these sites. As such, this offering represents a subsidy; it’s below our costs. That has three main consequences:

  • Non-Production Sites may not be used for production services, or for sites that generate any kind of revenue. If you’re making money on your site, we’re not willing to lose money to host it. Personal sites are OK. Beta sites are OK. Development sites are OK. Resume and portfolio sites are OK.
  • Non-Production Sites must constitute no more than half of the sites on your membership, rounded up. So if you’ve got one site, it can be non-production. If you’ve got more, you’ll have to maintain a mix. If your ratio falls out of balance (e.g. by deleting Production sites), we’ll apply an adjustment charge.
  • Non-Production Sites will help us improve our service. When we need sites to help test new features in the future, those sites will be automatically drawn as needed from the pool of Non-Production sites. They will also be limited to upcoming stable, beta and experimental realms to help us make sure third-party software updates are production-ready. (Realms are the huge collections of third-party software we provide preinstalled for all sites. Stable realms are rotated quarterly, and beta and experimental realms receive continuous rolling updates.)

If any of those limitations are undesirable for any reason, then a Production Site will be the more appropriate option.

We’ve found it’s faster, easier, and cheaper for us to develop and test new functionality when we have a robust base of real-world sites to test against. Our free bandwidth beta is a good example of such a test. That’s valuable to us, and that’s why we’re willing to offer this service at this price. We’ll make every effort to limit testing to sites that are compatible with whatever is being tested, and if the test breaks a site we’ll either opt it out if we detect that, or provide you a way to do so. And we’ll spread tests around to the best of our ability; it’s not our intent to draft every site into every test.

Whether or not a non-production site is participating in a test, we’ll still take feedback and problem reports about them, and we’ll still do everything we’re currently doing to keep them up and running.

Since this plan represents a subsidy, we have a certain amount of money in mind that we’re willing to “pay” our members for giving us the extra flexibility this plan provides. We’ll periodically evaluate the total number of non-production sites and may adjust the cost of this option if adoption rates are materially higher or lower than we expect. If needed, changes will be infrequent and announced in advance.

Each non-production site will also be able to use at least one gigabyte of bandwidth per day without being charged extra.

Production Sites ($0.05/day)

Production sites are the closest equivalent to current sites. As such, there’s not much to say about them. They will have full access to all features and realms, support static and dynamic content, and may be used for any production or revenue-generating purposes. There is no restriction to the number of them you can have. They may have some ability to opt into future tests, but that ability may be limited.

Although we won’t require it, we strongly recommend that if you are generating revenue from a production site, you should have a subscription membership. The cost is very small and if there is real money on the line then being able to ask for our insight and help when there’s a problem can be invaluable. It’s a good investment in your own success.

Each production site can use at least ten gigabytes of bandwidth each day without being charged extra.

Critical Sites ($0.50/day)

This is a new category of site available only to subscription members. It reflects a generalization of an informal arrangement we have with a few of our existing members who have sites that need special monitoring. This service is for sites that are particularly sensitive or important, sites that aren’t for the business, sites that are the business.

The higher price includes a custom entry for the site in our network monitoring system. That notification can be set to alert you, us, or both, in the event of a disruption. (We do reserve the right to adjust how vigorously it notifies us based on the frequency of monitoring events that result from issues determined to be under your control.) In the event of a disruption to our service, we will use the additional monitoring to ensure that service is restored as soon as possible.

Also, with critical sites, if we detect an issue, we will be able to devote more effort to investigating what’s going on to see if there is any helpful information we can proactively provide to the site operator, or if there is anything we can do on our end to help restore proper operation.

This doesn’t change the fundamental do-it-yourself nature of our service, nor will it keep sites online if they are hacked or compromised. To give an example, if we detect a WordPress blog is compromised, we disable it and our system sends out an automated notification via email to the site operator to let them know to take care of it. If that site were a critical site, we would still have to disable it, but we would send out a manual notification instead, including whatever information we can find about what’s going on, and if it were agreed upon in advance, we’d be able to alert the site operator by SMS as well.

If your site is vital to your business or generates enough revenue that you feel that a little extra attention is worth it, this is the option for you.

Each critical site can use at least 100 gigabytes of bandwidth per day without being charged extra.

General notes on site types

All site types will have full access to static and dynamic content, daemons, scheduled tasks, TLS, the ssh command line, and many other crucial features for modern sites.

With respect to bandwidth usage, each site type specifies an amount per day that won’t be charged, and that amount says “at least.” Officially, the policy is that usage in excess of the stated amount will be billable at the flat price of $0.10/GiB. However, right now, we don’t actually plan to bother keeping track of that. The goal is to cover our bandwidth costs, which are driven by attacks, not regular usage. If we’ve already charged you for inbound bandwidth to protect from attacks as part of the base site cost, we shouldn’t need to charge you again for outbound bandwidth because it’s already been paid for. So as long as site charges cover the bandwidth costs, as we expect them to, we can hold off on charging for overages. Naturally, if a site starts to use so much bandwidth that it’s becoming problematic, we’ll deal with it, but for now I kinda want people to give it their best shot. 🙂

The other “catch” is that it will be possible to upgrade sites to a higher plan, but it will not be possible to downgrade to a lower plan. Once a site is upgraded, that upgrade is permanent. Likewise, the daily costs will continue to apply even if the site is disabled.

This change will become effective for new sites on November 1st. At that time, existing sites will remain unchanged, but will be charged as Non-Production Sites. The option to choose a plan will be available in the UI on that date.

Starting December 1st, all existing sites that have not chosen a plan will be treated and billed as Production sites, but they will still have the option to make an initial plan selection. (So if you don’t get to this before the deadline, you’ll still be able to choose Non-Production for existing sites.)

Resource cost reductions

CPU and RAM resource charges for all site types will also decrease dramatically, from 17.22 RAUs per penny to 44.64 RAUs per penny. That’s a decrease of over 60% and will apply to both MySQL and sites. It should help make hosting larger, more active sites more affordable.

The pricing for storage resources will remain unchanged for now. The reliability of our current storage has been very good, but the cost (to us) is really high in terms of both TiB/$ and IOPS/$, and that shows through in the pricing (to you). We want to bring this down, and if we can stop spending every penny we have on bandwidth, I believe some more R&D in this area will really pay off.

Domain Registration

Since 2006, we’ve used the services of a third-party company to offer domain registration. That worked out really well for many years. Then, in 2014, that company was acquired by another, much larger, company. Its new parent owns a large number of other hosting companies that compete directly with us.

Initially, things were fine. But over the past twelve months or so, there have been a few incidents where our customers didn’t get the quality of service we expect. We’re concerned that it will be increasingly problematic to outsource such a critical function to a company that is essentially owned by the competition. Not to mention our lack of control over things that are very frustrating to us and our members, like “monetization*” of expired domains, is getting pretty old.

Unfortunately, the other wholesale options in the industry really aren’t any better. To make a material difference, we need an ICANN-accredited registrar. That’s a complex and expensive undertaking. To that end, we’ll need to raise prices on domain registration, first to fund the accreditation effort, and then to meet the additional ongoing requirements ICANN imposes on accredited registrars in a way that will provide a quality of service that both we and our members will be satisfied with.

The fixed costs of operating a registrar are particularly burdensome for smaller companies like ours that can’t amortize those costs over millions of names, especially if we don’t want to get any “monetization*” on us. Accordingly, we will raise the price of all domain registrations by $1.00/year on October 1st and use that money to pursue domain registration independence.

*”Monetization” is a technical term used by the domain registration industry that means “we’ll do anything, however scummy, if there’s money in it.” It’s never a good thing and it has to be handled with scare quotes because if you get any on you, the smell never washes away.

Enforcing our Terms & Conditions of Service

Our Terms & Conditions of Service are some of the shortest and easiest to comply with in the industry. Over 99% of our members are happy to do so. But the ones who don’t are getting to be a real source of hassle and frustration for us. People don’t follow our policies, they create a jam for themselves, and then they invariably expect us to fix that jam for them. And we have enough members that even “less than 1%” is enough people to cause a steady stream of headaches.

Unlike, say, DDOS attacks, these are avoidable problems that people absolutely did bring on themselves, and for which they alone should bear the costs and consequences. That’s not currently the case. You’re paying for their mistakes.

Effective immediately, if we detect the following situations, we will apply a $50.00 fee (per incident) to cover the cost of having our staff clean up the mess and advise the people involved on how our service works and what they should be doing instead:

  • One person who has multiple memberships. We will consolidate the multiple memberships into one membership with multiple accounts. (Definitely do not create multiple memberships trying to get around the per-membership limit on non-production sites!)
  • Multiple people sharing access to a membership. We will reset the password, get ID and a promise not to do it again from the named member, and provide references to documentation on how to use our powerful account sharing features.
  • Memberships that have been transferred from one person to another. We will require the recipient to transfer the membership back to the named member or, if we are unable to establish who that is, have the person create a membership in their own name, pay the $50 fee, and then we will transfer any accounts on the invalidated membership to the new person.

Pretty much, unless you’ve done something it says in bold print not to do on our signup page, you should never see this fee. But we’ve got to get the people who think they are exempt from what few rules we have to either straighten up and fly right or find some other host. Really, we’re fine with either choice.

If you are currently doing one of these things and we haven’t caught you yet, you will have until December 1st to take steps on your own to resolve the issue. We will waive the $50.00 fee if we learn about a violation from your good-faith effort to correct it. (E.g. if you request a transfer to consolidate your two memberships before we find out about it, we will process the request without applying the fee if it is submitted before December 1st.) If you need our help to resolve the issue before then, you’ll need a subscription membership, which is a much better deal than this fee.

Final thoughts

It’s very likely as a result of these changes, members paying more than a few dollars a month will wind up paying less, possibly substantially less. They’ll probably be very happy. But there aren’t very many of those.

There are others who will be able to make a few changes to consolidate usage and keep their costs about the same. Our per-alias site root feature may be particularly helpful for people with large numbers of static sites.

But, taken on a purely percentage basis, these changes are a large increase for many people. In many cases, that increase will be from pennies per year to dollars per year. Some of them will see the value in taking these steps and will be happy to pay more to support them. Some people… won’t.

For those who need it, it’ll still be possible to host a site with us for well under a dollar a month, and while that option is not without tradeoffs, that site will in many cases be able to do more than it could in the past.

For those who can afford it, and those who want us to support their business, we’re asking them to do a little more to help support our business in return.

A fair amount of this change is motivated by the inescapable truth that offering service at the price we’re offering it increasingly requires making compromises on the quality and future viability of our service. We’re not willing to do that. I have always believed that we are about offering a good value rather than the lowest price, and these changes reflect that goal.

For people who would prefer to accept those compromises to get the absolute rock-bottom price, there are and always will be providers who are willing to make them. But we are already farther down that road than I am comfortable with. I don’t like it here, and I don’t like what I can see ahead. We are changing course. We hope you’ll follow the new path with us, but if not, we’ll definitely understand.


RSS feed for comments on this post. TrackBack URI

  1. No worries, mate! NFSn’s prices have remain relatively unchained for almost (over?) a decade, while all other costs continue to go up and up and up. Totally understand, and totally on-board. Given light though of CloudFlare’s offering of free DDoS protection to everyone, is that not something worth looking into rather than buying huge PaloAlto NGFWs? (Which by the way if that’s what you ARE looking at moving towards – PANOS sucks!)

    Comment by gme — September 25, 2017 #

  2. Check their comparison of pricing tiers; Cloudflare does not provide free DDOS protection. At the free tier, they only provide CDN services. That’s not nothing, but it’s not DDOS protection either.

    Many of our members do use their free service, and we are aware of multiple occasions where those sites were targeted and CloudFlare told them to pay up or shut down.

    Free services are, in the general case, worth every penny.

    Cloudflare does not offer service to providers like us. Commercial DDOS services generally don’t, and those that do are still businesses looking to make a profit, so the costs are everything it would cost us to do it, plus a healthy markup.


    Comment by jdw — September 25, 2017 #

  3. I feel your pain. Well, I don’t really, as I’m not in your business, but I think I understand everything and I don’t plan to move because of it. Perhaps do a little more consolidating of sites, but that’s it.

    Comment by Scott Robison — September 25, 2017 #

  4. Sounds reasonable to me and the pricing still looks like good value for my purposes, so I’m fully on board with the new changes.

    Comment by bkc — September 26, 2017 #

  5. Thanks for being upfront about this. I reckon I’ll be sticking around a while longer.

    My instinctive first thought is “Hmm, I’d better wind up some of those old static sites I have lying around.” Is that something you’re looking to incentivise more? Or just a side effect?

    Comment by Rocky — September 26, 2017 #

  6. It’s expected that lots of unused static sites will get cleaned up, but it’s not a primary consideration. We have noticed in the past that not charging for X tends to result in a buildup of unused X’s lying around. That’s untidy, but it’s not a major issue and certainly not a looming crisis like the more urgent issues being addressed here. So, “side effect” I guess.


    Comment by jdw — September 26, 2017 #

  7. Thanks as always for keeping us in the loop, both about upcoming changes and the rationale behind them. I appreciate your priorities and am happy to chip in for better service for everybody.

    Comment by Finn Ellis — September 26, 2017 #

  8. Our per-alias site root feature may be particularly helpful for people with large numbers of static sites.

    Does this mean I can host and from the same site, serving different pages? Could you point me in the right direction? Up to now you have suggested to use a new site for each sub domain but if I’m reading this right this will no longer be practical for people like me who don’t make money off their web presence.

    Comment by Fb — September 26, 2017 #

  9. We don’t suggest anything one way or the other. You’re in the best position to decide what features your site needs. The per-alias site root feature is documented in our FAQ.


    Comment by jdw — September 26, 2017 #

  10. As a customer, I really appreciate this transparency.

    Comment by Porter Hall — September 26, 2017 #

  11. What about static sites set up for redirection according to these directions? Will they also be charged?

    Comment by Jake Wartenberg — September 26, 2017 #

  12. All sites will be charged for whatever plan they are on. That usage is only recommended to redirect to external sites. As the FAQ indicates, the correct way to redirect sites hosted here is via a hard canonical name, which does not require an additional site.


    Comment by jdw — September 26, 2017 #

  13. when will these changes be effective ?

    Comment by Baudouin — September 26, 2017 #

  14. The effective dates for these changes are in the article.


    Comment by jdw — September 26, 2017 #

  15. I switched all of my sites over from another company just a few weeks ago. Rather than feeling “burned” that, after moving to NFS the prices are going up, upon reading your honest post about the reason that prices must be increased, I think I’m more satisfied with my choice to switch than ever.

    You very clearly explain why it’s necessary, and that straightforward approach is really what I have appreciated about NFS since hopping over here.

    I’d much rather deal with a price bump and see this service stick around than have to move everything again and go back to one of the slimy big hosting companies.

    Comment by Hunter — September 26, 2017 #

  16. I’m in the NFSN decade club, and this post makes me proud to remain a loyal customer and roll with these totally reasonable changes.

    There’s one weird thing from my perspective:

    > The other “catch” is that it will be possible to
    > upgrade sites to a higher plan, but it will not be
    > possible to downgrade to a lower plan. Once a > site is upgraded, that upgrade is permanent.

    Because I’ve run “critical” sites that became less critical over time, I’d suggest a little bit more flexibility here. Perhaps you could allow a downgrade after some period of time?

    Re: Cloudflare DDOS protection, here’s a timely(!) update to that:

    Comment by Pat — September 26, 2017 #

  17. Should such a situation arise, it’s certainly something we could look at. Most “critical site” functionality will be handled manually anyway.

    It’ll be interesting to see what Cloudflare does now when the cost of mitigating an attack greatly exceeds what a customer is paying, especially in cases where the customer isn’t paying anything. Maybe they have so much money now that they just don’t have to care about that. Must be nice!


    Comment by jdw — September 26, 2017 #

  18. Excellent. Keep up the good work.

    The domain registration thing has always been a bit of a sticking point with me, partially because it’s hard to say “we’ll host any content that’s legal in the United States that the member has a right to distribute” while using a registrar that’s not based in the US and not subject to US law. Bringing domain registration “in house”, so to speak, would significantly improve things in my view, as well as making other options like adding DS records (hopefully) easier to implement.

    The new pricing structure will cause me to move a few sites onto the service that I had previously moved off of the service and onto a Raspberry Pi hosted at home due to their (a) being dynamic, necessitating a daily charge; (b) required a database process, again necessitating a daily charge and RAU usage); (c) being personal sites not making any incoming; and (d) getting very light traffic, and so not really justifying the outlay of costs (particularly RAUs for the mostly-idle database process). Since all sites will now have a daily charge, the distinction between static/dyanmic sites isn’t really relevant anymore. Even with the “production site” costs, the lower RAU charges make the overall cost a bit more reasonable for me. It will be nice to have these sites back on a proper host.

    I much prefer a reasonable fee for service that corresponds to the fixed costs needed to provide for the existence of the service and usage fees for resources consumed over a “flat rate for ‘unlimited’ resources”. With the latter, the provider is incentivized to promise the world but under-deliver, while the former allows the provider to grow as the needs of its customers do. That’s one of the things I like most about NFSN.

    That said, I’m very interested to see “largely ideological” posts you mention at the beginning, as well as the evolution of your thoughts over time. Although the content on my sites are wholly inoffensive (unless you consider discussion of the internals of microchips to be offensive), I am a firm believer in free speech and for NFSN’s libertarian-leaning TACOS, even if it means that unpleasant people share some of the same resources (and make my sites innocent bystanders in attacks) as mine.

    Comment by Pete — September 27, 2017 #

  19. 100% supportive of these changes.

    Comment by Lance — September 28, 2017 #

  20. There is no-one else in the industry who is quite so open, conscientious and disciplined as whoever runs this outfit.

    Keep doing what you’re doing, I would rather pay a few more cents per month than you suffer constant DDoS attacks that take down the service!

    Signed, a very happy user

    Comment by Mike — September 28, 2017 #

  21. Appreciate the verbose posts because it explains what you’re doing and why. Very loyal to NFS and appreciate all you do that I don’t see you do.

    Comment by Richard — September 28, 2017 #

  22. A quick calculation for my three sites suggests that I will be be paying more than 8 times the previous price. This sounds bad, but two production sites and one non-production one will still only cost $40.15 a year – which is a fair price. What’s more, I appreciate the fact that you’ve clearly and eloquently explained why that new price is necessary.

    So I fully expect to stick with NFSN for the foreseeable future, and I hope the change will make your excellent service more sustainable for the future. And good luck with the ICANN accreditation, the world needs a decent domain registrar. 🙂

    Comment by jimprdx — September 28, 2017 #

  23. I fully support your new model, and appreciate your openness as well as your commitment to quality. You have the best hosting in the business, and I’m looking forward to buying your service for years and hopefully decades into the future. Thanks for everything.

    Comment by Will — September 29, 2017 #

  24. What counts as revenue-generating?

    I manage the hosting for the website of a nonprofit organization, and while the website’s purpose is not raising revenue, there is a Donate button and visitors do click it from time to time (which sends them to a PayPal page right now). There are more indirect ways in which we raise revenue through the website (such as the membership sign-up page and the Amazon links in the reading list). On the other hand, nothing on the website ever takes anybody’s credit card numbers or anything like that, and the vast majority of the site has nothing to do with raising revenue.

    (With the drop in resource charges, we’ll probably stick with a Production site anyway, but I’d like to be able to report what our options are.)

    Comment by Toby Bartels — September 29, 2017 #

  25. A site does not need to be revenue generating to be a production site, although what you describe does count as revenue-generating. Basically, if the site is for any type of organization and is accessible to the public it needs to be a production site, whether or not it is revenue-generating.

    Another way to characterize revenue-generating is whether or not you or your organization could lose money if the site is down. If so, it’s revenue generating. If not, but you or the organization depend on the site in some other non-monetary way, it’s still a production site.

    (This would arguably require personal resume and portfolio sites to be production sites, which is why they’re specifically called out as eligible for the non-production tier. For organizations, only beta/development sites are eligible for non-production status.)


    Comment by jdw — September 29, 2017 #

  26. OK, thanks. I guess that ‘the site is for any type of organization and is accessible to the public‘ falls under ‘production services’ in the definition of what a Non-production site can be. (My mind must have skipped over that vague phrase entirely and latched onto the next bit about generating revenue.)

    We don’t really depend on our website for money (we could easily survive removing those bits), but we do depend on it (we’d have to rely on Facebook for communication, which is not reliable at all), which is why I was always planning to recommend that we pay for it. But thanks for the clarification.

    Comment by Toby Bartels — September 29, 2017 #

  27. What will happen to sites on Legacy (non-RAU) Billing? Same transition/timeline?

    Comment by Midoribe — September 29, 2017 #

  28. “Legacy Billing” sites don’t get/need any special treatment under the new plans. They will see the new plans & daily charges, same as the current sites, but they will be able to continue to pay 10x more for storage and not be billed for RAUs, if they choose.

    It’s already not a good deal for most sites financially, and that will be exacerbated by the drop in RAU costs. The number of legacy billing sites has already fallen sharply, and we expect more people will move off of it to save money after the change, placing increased pressure on those legacy sites that use excessive resources without paying for them.


    Comment by jdw — September 29, 2017 #

  29. Could you please provide more details and an example of calculation of the adjustment charge? Perhaps for someone with two production and three non-production sites?

    Comment by Midoribe — September 29, 2017 #

  30. The adjustment charge isn’t complicated. If your ratio is out of whack, it will just be whatever the difference is between what you’re paying and what you’d be paying if it wasn’t. In essence, it’s $0.04/day per “excess” non-production site.

    In the example you cite, there are no excess non-production sites. You reference 5 sites, so the non-production limit is 5/2 = 2.5, which rounds up to 3.


    Comment by jdw — September 29, 2017 #

  31. The main thing I do is anonymously hold a couple domains I own, and forward email from those domains to my actual web email address. All of what I have would be considered non-prod. None of my domains resolve to actual web sites.

    So I pay for anonymizing and the bandwidth to move all that email around, I guess. It’s a few pennies a day but it can be higher when somebody decides to spam me. The idea my account balance can be gobbled up handling email I didn’t want or ask for is the only thing I dislike about hosting this way.

    I didn’t see email hosting mentioned among the changes. Is email bandwidth now going to be considered within the overall site bandwidth, or is the current pricing model going to remain?

    Comment by NobodyKnowsMe — September 29, 2017 #

  32. There are no changes with respect to email forwarding pricing at this time. -jdw

    Comment by jdw — September 29, 2017 #

  33. I began using this service 2 months ago to set up a personal website while I hunted for jobs and didn’t have the income for a more expensive service at the time. For a while My fees were only about $0.60 a month, which was a steal for the benefits over the free hosting service I had been using before.

    I use this service for your philosophy and transparency, which allows you to create a sense of trust with your customers. Good luck in your changes!

    Comment by Andrew — October 1, 2017 #

  34. Your transparency and willingness to explain clearly and in detail what drives the decisions at NSFN are inspiring and confidence building. Thank you.

    Comment by Matt Wilkie — October 2, 2017 #

  35. It would be a good idea to put the dates of the changes into the short summary at the top of the page. At the moment one has to search for the dates in the lengthy text.

    Comment by BKB — October 3, 2017 #

  36. Good suggestion! I’ve done that. -jdw

    Comment by jdw — October 3, 2017 #

  37. I am one of the people who will be greatly affected by this pricing change.

    I am currently paying pennies a month, but it seems that I will have no choice but to start paying 5000% more for my sites if I want to keep using NFSN.

    While I applaud the transparency in pricing models, and what drives pricing changes, I am disappointed at the (from my perspective) exorbitant price increase. I suppose time will tell if the increased price is worth the benefits.

    Comment by Ben — October 3, 2017 #

  38. A 5000% increase from “pennies a month” is a couple of dollars per month. It’s up to you to decide if that “greatly affects” you.

    If you’re in that situation, it is likely because you have several static sites. That’s exactly the setup that can (as described in the post) benefit from consolidation using features like per-alias site root. So you probably do have options to mitigate some or most (but not all) of the increase. The more small static sites you have, the more you will benefit from consolidating them.


    Comment by jdw — October 3, 2017 #

  39. Still using the service, still recommending it to (tech-savvy) friends. Quality and transparency are tremendously appreciated. You guys rock.

    Comment by Josiah — October 3, 2017 #

  40. Reguarding domain registration, I like the idea of having my domain hosted here. If we prepay our domain out a few years, are we going to be stuck with different domain hosting when you transition to hosting? If so, do you foresee issues with domains having different support/features based on where they reside?

    Comment by Josiah — October 3, 2017 #

  41. It’s a little early to have specifics on the future of domain registration or exactly how a transition will work. However, most domain related services are provided by the TLD registry, not the registrar, so the differences — if any — are likely to be slight.


    Comment by jdw — October 3, 2017 #

  42. Can I elect to keep a site static? (I’m not asking for a discount for doing so.) I don’t have any interest in dynamism, and I’d rather a smaller attack surface and less room for mistakes.

    Also, did y’all send an email about this? I happened to see the notification when signing in, which I don’t do regularly, and I was quite surprised I hadn’t received an email. Alternatively, I may have an overly aggressive spam filter to correct.

    Comment by Jude — October 8, 2017 #

  43. Yes, static sites will continue to be an option for exactly the reasons you specify. They are also load balanced separately, so if your site is static, it is less likely to be affected by anything some other site might do. (We take steps to prevent that with dynamic sites, but using a static site effectively removes it as a possibility.)

    We haven’t sent any emails about this yet. In the past, we’ve tried it both ways and we get more “stop spamming me!” complaints from doing it than we get “you should have emailed me!” complaints when we don’t. In this case, since the relevant UI isn’t available yet, sending email would be premature. Once that changes, the UI will call attention to the new settings in a couple of different ways. Then, as we get closer to December 1st, we’ll take a look at the status quo and see if we can find a way to identify people who might not be aware of the change.


    Comment by jdw — October 8, 2017 #

  44. All seems reasonable; thank you for being up-front and transparent.

    One remark: You’ve stated that sites will continue to accrue charges when disabled. Combined with the inability to downgrade a production site to a non-production site, this makes the use case of two WordPress sites that get switched between being “live” and “staging” every so often a bit awkward (also, I imagine, similar usages which are probably not all that uncommon). The live site certainly ought to be a Production one, but I can’t justify them both being, for a small charity, if the staging site accrues fees when disabled (which is most of the time). I think the only remaining approach now would be to create a brand new staging site each time, and nuke the old live site each time. Which is considerably more hassle.

    If you’re set on charging for disabled sites, and on disallowing downgrades (I’d favour a “once upgraded you can’t downgrade for n months” approach myself), then how about an option to duplicate a production site to a non-production copy, keeping not only files but things like cron entries and so forth?

    Comment by Simon — October 8, 2017 #

  45. You can certainly go with the option to create a new site and delete the old one if that best fits your deployment methodology.

    Most people with the need to maintain content on multiple sites use version control, e.g. a central git repository with “production” and “development” branches. They then merge changes from development to production when they’re ready to go live, without the need to play shell games with sites.

    We do hope to make it easier to share and transfer content between sites in the future.


    Comment by jdw — October 8, 2017 #

  46. As a barely-technical member, I tried to parse the per-alias site root FAQ entry but am somewhat confused. We have multiple static sites that are pretty much “parking” for domains we want to keep alive (for e-mail etc). They are unrelated, but pretty much have just one page and that’s it. Would these have to be converted to production sites, or can they be consolidated via per-alias site root?

    Comment by Ai — October 8, 2017 #

  47. It’s definitely possible to use per-alias site roots. If you need assistance with that, feel free to ask via the forum, or support if you’ve opted for subscription membership. -jdw

    Comment by jdw — October 8, 2017 #

  48. I would appreciate having some kind of automatic calculator for what the new charges will be. It would be better if the data was automagically from current/recent billing data, but I’m fine with re-entering it by hand if that’s less of a programming nightmare.

    (The numbers I calculated by hand suggest that I will probably see a slight decrease in my costs, but I might be figuring it wrong.)

    Comment by Shawn — October 9, 2017 #

  49. The Pricing Estimator will be updated on (or around) November 1st. To determine expected resource usage charges, since resource usage is not a constant, you can look at past usage to determine what future pricing will be, but the actual cost will be based on actual usage. All we can say for sure about that is that it’ll be about 60% less than it would have been without the reduction.

    The basic site pricing is about $1.50-1.55/month for a production site, and about $0.30-0.31/month for a non-production site. These charges won’t vary, so they should be extremely easy to calculate.


    Comment by jdw — October 9, 2017 #

  50. “For those who can afford it, and those who want us to support their business, we’re asking them to do a little more to help support our business in return.”

    No problem here–take my money, please!

    Seriously, thanks for continuing to run such a fantastic service.

    Comment by Douglas Muth — October 12, 2017 #

  51. I’m willing to continue supporting you for what you represent, as long as costs don’t become excessive. Thanks for all the good that you’ve done.

    Comment by scott stornetta — October 12, 2017 #

  52. Totally on board with these new changes. Thanks for the great service over the years.

    Comment by Ron — October 13, 2017 #

  53. At first I was sad I might have to pay more money for my extremely low-traffic hobbyist ventures, even though you explain very clearly here why you have to and I accept that it’s necessary. However, now that I’ve found out that the per-alias site root thing is a possibility, my costs should actually stay much the same! (In fact, cheaper if I’m not mistaken, because I merged my two dynamic sites into one.) That was a pleasant surprise. Thank you so much for the good work you do, and the extremely cheap hosting I’ve benefited from over the years!

    Comment by Jessica — October 13, 2017 #

  54. I enjoy using the Nearly Free Speech service enough, throwing a few more dollars a month into the wishing well is perfectly fine! Over the past 6+ years of using the service I have had no issues hosting my business and personal sites. I expect the next 6 years to be just as great!

    It is still 100% “Nearly Free”… ooh you know. 🙂

    Comment by Derek — October 13, 2017 #

Leave a comment

All comments are moderated; off-topic comments, requests for tech support, and trolls will not be approved. This blog is our free speech platform, not necessarily yours. If you wish to contact NearlyFreeSpeech.NET, please visit our site or email support@NearlyFreeSpeech.NET.

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Entries Feed and comments Feed feeds. Valid XHTML and CSS.
Powered by WordPress. Hosted by NearlyFreeSpeech.NET.