NearlyFreeSpeech.NET Blog » Significant pricing updates are coming soon

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.

The cost and threat of DDOS attacks is escalating so quickly that unless we act, they will drive us out of business.
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 (plan selection available on November 1st, existing sites with no plan billed as Non-Production as of November 1st, and as Production sites as of December 1st):
- 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.

jdw | September 25, 2017 | In News & Announcements, Policy Changes | 103 Comments

103 Comments

RSS feed for comments on this post.

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 #
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.

-jdw

Comment by jdw — September 25, 2017 #
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 #
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 #
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 #
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.

-jdw

Comment by jdw — September 26, 2017 #
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 #
Our per-alias site root feature may be particularly helpful for people with large numbers of static sites.

Does this mean I can host 1.x.com and 2.x.com 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 #
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.

-jdw

Comment by jdw — September 26, 2017 #
As a customer, I really appreciate this transparency.

Comment by Porter Hall — September 26, 2017 #
What about static sites set up for redirection according to these directions? Will they also be charged?

Comment by Jake Wartenberg — September 26, 2017 #
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.

-jdw

Comment by jdw — September 26, 2017 #
when will these changes be effective ?

Comment by Baudouin — September 26, 2017 #
The effective dates for these changes are in the article.

-jdw

Comment by jdw — September 26, 2017 #
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 #
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:
https://blog.cloudflare.com/unmetered-mitigation/

Comment by Pat — September 26, 2017 #
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!

-jdw

Comment by jdw — September 26, 2017 #
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 #
100% supportive of these changes.

Comment by Lance — September 28, 2017 #
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 #
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 #
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 #
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 #
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 #
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.)

-jdw

Comment by jdw — September 29, 2017 #
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 #
What will happen to sites on Legacy (non-RAU) Billing? Same transition/timeline?

Comment by Midoribe — September 29, 2017 #
“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.

-jdw

Comment by jdw — September 29, 2017 #
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 #
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.

-jdw

Comment by jdw — September 29, 2017 #
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 #
There are no changes with respect to email forwarding pricing at this time. -jdw

Comment by jdw — September 29, 2017 #
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 #
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 #
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 #
Good suggestion! I’ve done that. -jdw

Comment by jdw — October 3, 2017 #
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 #
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.

-jdw

Comment by jdw — October 3, 2017 #
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 #
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 #
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.

-jdw

Comment by jdw — October 3, 2017 #
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 #
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.

-jdw

Comment by jdw — October 8, 2017 #
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 #
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.

-jdw

Comment by jdw — October 8, 2017 #
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 #
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 #
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 #
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.

-jdw

Comment by jdw — October 9, 2017 #
“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 #
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 #
Totally on board with these new changes. Thanks for the great service over the years.

Comment by Ron — October 13, 2017 #
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 #
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 #
Sounds more than fair! NFS.NET has been a fast and reliable host for my sites, and that’s what matters to me. I have no reason to leave just because of a slight price increase.

Comment by Ectropy — October 17, 2017 #
Sounds fair! I’m happy to know you’ve come up with a reasonable solution and didn’t compromise the standards that got you most of the clients in the first place. A rare example of a great idea / company continuing to be great…

Comment by Benji — October 18, 2017 #
Will using per-alias site roots lower your costs such as by lowering your exposure to attacks and mitigation costs? Unless it does something financiallly like that, although my personal income is low (and my website advertising earnings have reached, as of the last time I checked, a yet-uncollectible four cents), I’m hesitating to use that feature for several static sites, as I think that would undermine your vital effort. I’m getting close to rolling out a new site that’s likely much larger than any other of mine and I don’t want to weaken your position.

Comment by Nick — October 22, 2017 #
Lowering exposure to attacks? Not really. If you have five hostnames, one site with five aliases is somewhat more resource-efficient for us than five separate sites — the “walls” between sites do carry a cost, even for static sites. Spreading out anti-DDOS costs based on # of sites is not perfect, it’s just better than the other options.

Voluntarily using our service in an unnecessarily less efficient way to increase your hosting costs is not a strategy I would recommend. You’ve got to do what’s right for you, and it’s our job to make the revenue and expenses add up. That said when we did our math, we assumed that the costs-almost-nothing static sites on memberships with more than one site would not translate into production sites (or even non-production sites) at anything remotely close to a 1:1 ratio.

That said, if someone wants to support us and help our efforts, that’s great. Our preferred ways for people to do that are (1) subscription membership, (2) do more with your hosting, and (3) tell your smart friends capable of succeeding with our service about us.

-jdw

Comment by jdw — October 22, 2017 #
It says something about how much of a free ride I’ve been getting that these changes represent something like a hundred‐fold increase in the amount I’ll be paying for the sites I actually use, and it’ll still only total $3 a month.

Hope these changes help you get more breathing room going forward, and no worries. ❤️

Comment by Kat Suricata — October 22, 2017 #
As always, thanks for the thorough and transparent explanation. I’ve been with you for six years now and I’m not going anywhere. I support these changes and will run my site as “production” even though it would certainly qualify for, and run fine as, non-production, because that’s still nearly free and your unique service is well worth every penny plus a few extra.

Also looking forward to reading those half-finished blog posts 🙂

Comment by Tom McNeely — October 22, 2017 #
Regarding current static redirect sites.

You mentioned above that a cost effective solution available if all sites are hosted here is a hard canonical name.

My question is can this be combined with per-alias site root feature? A cursory review of the hard canonical name feature suggests to me that these two features may not be compatible.

Currently I have multiple static sites redirecting to a single dynamic site using per-alias site root and it works well.

An additional aggravation to all this is that these static redirect sites are currently using the nfshost.com domain so my options are limited in terms of the ability to move the redirect sites “off site”. Thank You

Comment by Larry — October 26, 2017 #
Per-alias site roots are completely incompatible with a hard canonical name, so that setting must be off. You would use .htaccess instead in that situation. If you need help with that, check your support options as the blog comments are not a support venue.

There is a 1:1 relationship between sites and nfshost.com aliases, so if you want to use multiple names in that domain, you will need a separate site for each.

-jdw

Comment by jdw — October 27, 2017 #
Thanks for the advance notice—it’s helpful and appreciated. But I’m not going anywhere, and I’m recommending the same to the friends and clients I’ve steered to NFSN for their hosting. I don’t think I’ve ever had cause to complain. And it’s not lost on me that (I think) most other hosting services would have just said, “The prices are going up, and I don’t owe you any explanation.”

Comment by David Warrington — November 3, 2017 #
We felt the summary of effective dates added on October 3rd was potentially unclear, so we’ve made a small adjustments that should help avoid confusion.

The full text is clear and accurate and has not been changed.

-jdw

Comment by jdw — November 3, 2017 #
I am one of the users who was using only several static sites. But I will continue to use NSFN despite the price change. Because 1) I would like to support you and your noble cause 2) You are among the very few hosting providers who offer a “prepaid” option for payment

Love from India.

Comment by kichuku — November 4, 2017 #
It’s a real shame that this is where we’re at with the internet, having to put so many resources into thwarting constant attacks. Appreciate the detailed and transparent post, and I’m in no way upset with NFSN or considering moving elsewhere, the whole thing is just kind of a downer.

Keep up the good work, thank you for your commitment to providing value.

Comment by brhfl — November 6, 2017 #
I’m one of those people who thinks you really ought to send emails about things like this, BEFORE you change what you are charging. If my account balance hadn’t been getting low, I wouldn’t have signed in and seen this blog posting.

Aside from that, I’m totally in support of this change. My costs will increase about 400%, to a mere few dollars a month, which in my mind moves your service from “too good to be true” to simply “a very good value”! Keep up the good work!

Comment by Sean — November 6, 2017 #
Hello, my only feedback is to allow demoting sites from production to non-production or from critical to production or critical to non-production after a certain number of months (to reduce the abuse of this switching ability). I hope you’d consider that. Deleting a site and creating it again with content is a bit more tedious when we need to demote sites.

Thanks!

Comment by ms — November 9, 2017 #
At this time, we have no plans to allow “demoting” sites. That is not something that should be happening in the ordinary course of operation. If a site is no longer a production or critical site, it’s almost always because that site has reached the end of its life and has been discontinued or replaced. We may reconsider that in the future, but if so it would only be after a year or so once we have gathered additional information about how people interact with the new system and then only if we identify a specific use-case that such behavior would support. -jdw

Comment by jdw — November 9, 2017 #
Honestly this sucks … I was trying to keep a tiny (15MB ) static site up indefinitely for nostalgic reasons. The internet sucks in some ways, in many ways more history has been lost in the last 20 years than any time in the last 600+ years simply because a lot of content has been created and simply disappeared.

This will equate to around 271667% increase based on my previous usage. I get why you are doing this it just sucks that a few ass-hats can ruin things for the rest of us.

Ill be here till my deposit runs out which in reality will be a while just not as long as I had hoped.

Comment by Trae — November 11, 2017 #
Oh well, I guess I’ll be finding a new host. Your prices for hosting low bandwidth static pages were amazing, but I guess it was too good to be true.

So long, and thanks for all the fish.

Comment by Anthony — November 12, 2017 #
It it a dark day (long time coming) that an honest web host has to change their practices because of abuses by DDOS actors. It chills free speech and is expensive beyond belief for those targeted by them. I don’t know if these changes by NFS are better/worse for me personally, but I totally understand why and support anything that keeps a non-scummy host profitable.

Comment by Chris — November 12, 2017 #
I’m not sure what other people are seeing, but I am quite happy with the change. I carefully track my NFSN costs and my costs (3 personal WordPress sites) have gone from about 33 cents per day down to about 15 cents per day. Very nice. Thanks for the great hosting service.

Comment by Michael Goodson — November 14, 2017 #
Since it’s been discussed several times in the comments to this post, I wanted to mention here that we have changed the name of the “Per-Alias Site Root” feature to “Per-Alias Document Root” as that is a more accurate reflection of what it does.

-jdw

Comment by jdw — November 16, 2017 #
I understand the reasoning behind this significant change in the pricing structure. It’s a shame that a dark social phenomenon like widespread DDoS attacks against innocent website operators should make life difficult for everyone, but that’s apparently the way of it. -_-

It looks as if my longtime use of NFS to host dozens of tiny static sites meant to park domain names for eventual development has expired — I truly did mean to do something with them, but … well, that’s my problem.

Regrettably, I don’t think it makes sense to continue this practice with NFS under the new pricing structure. (Tech support request removed.)

Comment by Bumpy Light — November 16, 2017 #
I’m kind of disappointed. I have a static site that is basically legacy, and used only a few MB at best. Now I’m getting an automatic daily charge, and there was no email notification for this. (You posted on the blog, but there was no notification otherwise.)

Comment by Stephen — November 16, 2017 #
This change was announced well in advance through all the usual channels, including on our member site in two places, via Twitter, on our offsite network status page, and on the blog. We did exactly what it says we do, which is far from “no notification.” If you were looking for updates somewhere else, then I’m sorry, but you were looking in the wrong place.

In addition to that, as described above, we are now in the process of emailing people who are likely to be significantly affected by the change but have not thusfar taken action on it, even though that is not our usual practice.

If you have one static site, however, the impact on you is very small in absolute terms; hosting a small, low-activity site here — static or otherwise — will still cost just a few dollars a year.

-jdw

Comment by jdw — November 16, 2017 #
Thank you for explaining the reasoning behind the changes. That kind of transparency is very appreciated.

IMHO, NFSN’s prices are still perfectly reasonable. Even if they were higher, I’d pay them gladly to support a company like this.

Full support here for everything you’re doing — and best of luck with that ICANN accreditation.

Comment by Hazel — November 18, 2017 #
If DDoS is the main driver behind the price changes, why not use services like Reblaze (https://www.reblaze.com/) or something similar? It seems a more cost-effective and scalable solution than running your own equipment to handle the scale of bandwidth current attacks generate (and which no doubt will only grow exponentially in the future).

Comment by Amnon — November 24, 2017 #
See the second comment on this post, where this question has already been addressed. -jdw

Comment by jdw — November 24, 2017 #
Also proud of the transparency and seeing the improvements to the stability and future of the service. I was one of those Free(ish) users for years and have recently been working on a new startup. We well eventually start generating revenue and I am looking forward to flipping the switch to production or even critical site to support the service that has supported me over the years.

If all goes well I’d love to contribute even more to help subsidize those homeless that need a webroof over their heads.

Thank you

Comment by DjM — November 25, 2017 #
“Cloudflare will no longer terminate customers, regardless of the size of the DDoS attacks they receive, regardless of the plan level they use.” https://blog.cloudflare.com/unmetered-mitigation/

Cloudflare now has a full DDoS protection on all plans. And they have means to automate integration with them. As far as I understood your client could have a firewall from Cloudflare before their site with a push of a button from their CP without having to sign up with Cloudflare.

Comment by Alexey — November 25, 2017 #
In your reply to Pat, I wasn’t clear on why you seem to discourage CloudFlare use – or at least seem really negative about them. Wouldn’t all of your customers be better off if more of your hosted sites used CloudFlare? (I use it, though it’s overkill for the site I have on NFS). Given their pretty unambiguous statement in the link Pat provided (https://blog.cloudflare.com/unmetered-mitigation/), it sounds like their Surge pricing was nearly gone and now will be gone completely.

Maybe they won’t be perfect. Maybe your servers won’t be insulated from every DDOS attack. But wouldn’t you be protected from many?

If it is a pure good thing to get more people on that service, why not encourage it? Maybe provide links and even some basic pointers? It might even simply reduce your hardware needs, attacks aside, just from the CDN function.

Is it really just useless?

Comment by Max Rockbin — November 25, 2017 #
If individual members want to use Cloudflare, or any other similar service, they absolutely can and should feel free to do so. Cloudflare may be a good fit for them. It’s not a good fit for us.

Several of these types of questions basically come down to “Can’t you find somebody smart enough to protect you from DDOS attacks but dumb enough to lose money doing it?” And the answer to that question is no.

-jdw

Comment by jdw — November 25, 2017 #
I appreciate the openness and transparency in your explanation as to why the price going to be rising for some people (myself included). Additionally, I REALLY appreciate that you sent me an email at the very end before the change went into effect, because I only have a single personal site that for the most part is a “set it and forget it” site where I host a few files using 3rd party program to manage it and don’t actually log into the website more than once or twice a year usually, I would not have otherwise realized that my price was going up to the 5c plan until after it was too late to keep it at a 1c plan which I believe I am eligible for. It was nice that I was paying an average of maybe 1c per week before, but your reasoning for changing your services is completely reasonable and understandable, and I won’t be going anywhere.

Comment by Josh — November 25, 2017 #
Not to worry, if you miss the deadline, you can still pick a non-production plan later. If you don’t pick a plan for a site, that site will just be billed (and treated) as a production site until you do (after December 1st). -jdw

Comment by jdw — November 25, 2017 #
What about a holding site?

I have three domain names, all of which I’m looking to sell (but not actively promoting), so I have a static HTML page for each indicating that each domain is for sale.

Your earlier answer stated:

“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.”

I’m not an organisation; I’m an individual.

You then go onto say:

“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.”

I’m not losing money if the site goes down because it’s there for unsolicited offers nor are offers made through the site.

Does my use qualify as non-production or would I need to change it to production

Comment by General Query — November 25, 2017 #
For questions about whether your site is production or non-production, please see our FAQ. -jdw

Comment by jdw — November 25, 2017 #
Thanks for the e-mail about this and thorough discussion here.

I’ll happily pay the extra $1 per domain, which is my primary use for NFS. I may consider moving the single site I host here (which I inherited from a friend) over to my VPS; I would have done it long ago, but it wasn’t worth the effort for $3.65/yr. Non-production would probably be fine, but given that it’s my only site here, I really should consolidate it over there anyway.

And since I haven’t said it in a long time (if ever), thank you for being a wonderful, low-maintenance company since I first registered a domain with you in 2008. No spam, no hidden fees, no fancy but impossible to navigate web site. Just a simple service that does what it says on the label.

(Simple in the sense that it doesn’t take much effort for me, not that it’s easy on your end 😉 )

Comment by Evan Danaher — November 25, 2017 #
Thank you for the email notification. I am one of the folks that doesn’t follow twitter or the blog. I appreciate the transparency. Even though my costs are going to rise significantly, you guys are worth it. ❤

Comment by repscree — November 25, 2017 #
Thanks for the transparency. You are the best hosts in the business; I think I can eat the $3.65 a year. 🙂

Comment by Paul Gowder — November 25, 2017 #
Hi,

I’m fully supportive of the pricing changes and appreciate the rationale. Thankyou for your work!

One question, do you have roadmap dates for when you anticipate being able to purchase and install the additional equipment you mentioned to improve your DDOS mitigation rate from the ~70% up to the 85% to 95% rates you mention?

Thanks,

Comment by Mikaela — November 25, 2017 #
We’ll see about that after the beginning of the year, once we have a better idea of how these changes are going to shake out. -jdw

Comment by jdw — November 25, 2017 #
I greatly appreciate the eloquence and honesty of Mr. JDW about all of this. I also appreciate the reminder email. I have logged into NFSN a few times since his blog post yet somehow missed the announcement.

Comment by Keith — November 25, 2017 #
So much for “only pay for what you use” hosting 🙁 I had tailored my site to be static/low bandwidth/low storage. Now I’ll be paying whether or not I’m using bandwidth or storage. I’m very disappointed in these changes.

Comment by Chucky — November 25, 2017 #
As others have pointed out, it’s entirely possible to do quite a lot of hosting here for a few dollars a year. If that’s disappointing, I’m sorry to hear it, but we are not and have never pretended to be a free host.

-jdw

Comment by jdw — November 25, 2017 #
This is a crazy price decrease for me since I only run one dynamic site with a 24/7 daemon. I could even run it as “non-production” but will opt to run it as a production one. Good luck with the ICANN accreditation.

Comment by Gum — November 25, 2017 #
Thank you for the email – I have a single portfolio site with nothing fancy on it and would not have known about any of this without an email. And thank you for the transparent explanation; happy to continue to give you my business. I hope the new changes go smoothly.

Comment by HS — November 25, 2017 #
Sounds reasonable- especially if you do establish a full domain registrar that actually supports free speech. As we have learned, that would be the first such registrar. Good luck.

Comment by Paul Rain — November 25, 2017 #
thanks for all your work and transparency! despite doing away with ‘pay for what you use’, this is still an extremely reasonably priced service for the amount of flexibility and honesty, and that’s worth the cost for me.

Comment by hv — November 26, 2017 #
Most of our service remains pay-for-what-you-use, like disk, RAM, and CPU usage. Only bandwidth is moving away from that model because the people using most of it aren’t our customers, they’re attacking our customers. As much as we would love to make those people pay for what they’re using, we haven’t found a good way to do that. Yet. 😉 -jdw

Comment by jdw — November 26, 2017 #
“Protection isn’t optional. There’s no point in offering our service if the minute anyone calls our bluff we have to fold.”

I’ll be using this quote in the future. Well said. I support these changes and look forward to the growth and sustainability plan proposed by NFS. Keep on keepin’ on!

Comment by Adam — November 26, 2017 #
You guys are the best! Thanks for doing what you do.

Comment by Steph — November 28, 2017 #

Sorry, the comment form is closed at this time.

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

Significant pricing updates are coming soon

Summary of changes

About DDOS attacks & bandwidth

New site types

Non-Production Sites ($0.01/day)

Production Sites ($0.05/day)

Critical Sites ($0.50/day)

General notes on site types

Resource cost reductions

Domain Registration

Enforcing our Terms & Conditions of Service

Final thoughts

103 Comments

Categories:

Archives:

Significant pricing updates are coming soon

Summary of changes

About DDOS attacks & bandwidth

New site types

Non-Production Sites ($0.01/day)

Production Sites ($0.05/day)

Critical Sites ($0.50/day)

General notes on site types

Resource cost reductions

Domain Registration

Enforcing our Terms & Conditions of Service

Final thoughts

103 Comments

Categories:

Archives:

Links: