May 17th, 2015
For a few months now we’ve been asking for feedback when users cancel their accounts. One interesting thing we found out is that the majority of users are actually really happy with the service, they just use it in bursts and don’t need it consistently month-to-month. We’ve opted not to do on-demand billing from the start, mostly because it’s a hassle and can be hard to explain what you’re actually getting and when you need to pay more.
Many of our users use Forward everyday, some once or twice a week, and others only need it for certain projects. We felt bad for the users that don’t need Forward consistently, because it’s rather inconvenient for them to cancel, go through the signup process, and finally have to re-authenticate their Forward client every time they need the service again.
Today we’ve introduced pausing your account. There’s really not much to explain, if you’re a paying customer, you can pause at anytime and you won’t be billed again until you unpause. We think this will help out a lot of our users that need Forward, but don’t need it everyday.
If you have any feedback, as always, let us know at firstname.lastname@example.org
—The Forward Team
March 2nd, 2015
During the next week, our server host will be performing security updates on all of their servers.
Unfortunately, this means that Forward will experience some down time throughout the week. Each server maintenance has a two hour window scheduled, but the actual downtime could be much less.
Here are the dates and time (all times are EST) that our servers will be undergoing maintenance:
- March 3rd: 11 PM
- March 4th: 1 AM
- March 7th: 5 PM
- March 8th: 1 PM
Any downtime is never ideal, but we’re ready to make sure that Forward is up and running as soon as the servers come back online.
—The Forward Team
December 3rd, 2014
We’re very happy to announce that Forward v2 has launched! We’ve got a new look, a new-and-improved backend and client, and a totally new way to share your local sites.
Forward for Chrome
With the new Forward Chrome extension, you can now forward sites right from your browser without ever setting foot in the terminal. It’s as simple as pulling up your local site in Chrome, clicking the Forward icon, then clicking ‘Start tunnel’. A tunnel will start and its URL will be copied to your clipboard automatically, ready to share.
We’ve found this to be a really intuitive way to link to localhost, and we hope it will be more comfortable for the many developers out there who don’t spend all day in the Terminal.
This also means that you no longer have to install Ruby on your system before you can use Forward. This should be a big relief for many Windows users. Now you only have to install the Chrome extension to use Forward.
New CLI Client
Prefer the command-line? Don’t worry, we haven’t forgotten about you! The Forward CLI client has been completely rewritten and is now better than ever. Most of the changes are under the hood, but here are a few of the big new features:
The Forward CLI now supports multiple accounts. You can switch between your personal account and a company account easily. Run
forward --help to see the new options.
Forwarding Static Sites
If you’re working on a static site or need to share a directory you can now just run
forward your_path and we’ll start up a simple HTTP server for you. It even does directory indexes.
There’s now an option to have your URL automatically copied to your clipboard when a tunnel starts. It’s enabled by default, but if you’d like to turn it off just edit
~/.forwardrc. You can also have the URL opened in your default browser by enabling the option in that file as well. Small features, but our team has really been enjoying them and we think you will too.
We’ve also added logging to the Forward CLI client. This means you’ll be able to see any requests to your tunnel logged to the terminal. Even if you’re not logging from your dev server.
To get the new CLI, just run
gem install forward.
Annual billing and more
In addition to the new clients, we now offer annual billing for all of our plans, this is a great option for businesses or for people who prefer lump sum payments. The annual plans are available now. We’ve also beefed up our Help section with new articles, and have improved the old ones. We plan to keep adding to it, so let us know if there’s anything you’d like to see.
This is a big launch, so we appreciate your patience as we work out any kinks. Please let us know if you find anything amiss at email@example.com.
We’re very happy about this new version, and we hope you like it too. Feel free to give us any feedback on twitter @forwardhq or by emailing firstname.lastname@example.org
—The Forward Team
January 22nd, 2013
We just rolled out a new version of the Forward client, with a new feature that we’re pretty excited about:
When you’re using Forward with several projects, it can become tedious remembering which command-line options to use for each project. A
Forwardfile lets you set options within a flatfile in the project itself. You can even track it in version control if you want (but be careful not to track authentication credentials).
Most of the options that you would specify via command line switches are supported, and map one-to-one to the
Forwardfile. Also it’s just a YAML file, so you don’t need to learn any funky new syntax.
A few examples:
# Set the port to forward
# Set the host/vhost to forward
# Set a static subdomain prefix to use
# (e.g. myapp-yourcompany.fwd.wf)
# Set a CNAME to use
# Set a username and password
# Disable auth on this tunnel (useful if you have
# “require authentication" enabled in your preferences)
So how do you use them? First update to the latest version of the Forward gem. Then just create a
Forwardfile at the top level of your project and specify the options you want to set as shown above. Now cd into your project directory, and run
forward. Depending on how many options you’ve set in your
Forwardfile, you may not have to pass any option to the
forward command at all.
We use Forward a lot, and know that sometimes it gets a little crazy when you’re constantly jumping between multiple projects. We think
Forwardfiles are a good solution to the problem and we hope you find them useful.
January 18th, 2013
Last week, we rolled out a change to the Forward servers that changed the way a few of the request headers were passed to local servers. Today, we’ve rolled out another one.
Originally, when a request to a Forward URL got to the local dev server, the
Host header would be the Forward hostname, e.g.
example.fwd.wf. This worked great for most people, but created an issue for our customers who use Pow, MAMP PRO, or other virtual host-based setups. To solve this, we made it so that if you Forward a virtual host, the
Host header is set to your virtual hostname (e.g. example.dev), and we added the
X-Forwarded-Host header, set to the Forward hostname (e.g. example.fwd.wf).
Later, we discovered another issue when Forwarding a WordPress site that’s running on regular MAMP. Our WordPress plugin looks at the
X-Forwarded-Host header to fix the URLs in a Forwarded WordPress site, but we were only setting that header when Forwarding a virtual host. We decided that since Forward is a lot like a proxy, we might as well treat the request headers like one. So last week, we changed it so that the
Host header would always be the name of the host being Forwarded, e.g.
localhost, and the
X-Forwarded-Host would always be the Forward hostname, e.g.
But soon after we deployed that change, we started getting support emails and tweets about it. Turns out, lots of frameworks and dev servers rely on the
Host header to do redirects, dynamically construct URLs, and do many other things.
In almost all of these cases, it’s possible to configure things to work fine, but that’s a lot of hassle for a lot of our customers. And it’s not in the spirit of Forward. So we decided to make one more change.
As of today, when you Forward a site using just the port (i.e.
forward 3000), both the
Host and the
X-Forwarded-Host will be the Forward hostname (e.g.
example.fwd.wf). And when you Forward a site using a virtual host (i.e.
forward example.dev), the Host header will be your virtual host name, and
X-Forwarded-Host will be the Forward hostname.
We think this will work for the vast majority of users, without having to do any special configuration on their part.
Let us know if you have any issues!
— The Forward Team
January 9th, 2013
We’ve just launched support for using wildcard subdomains with your Forward URLs.
Now, for example, if your Forward URL is example.fwd.wf, requests for *.example.fwd.wf will be routed like you would expect. It works all the way down too: foo.example.fwd.wf, foo.bar.example.fwd.wf, and so on all work fine.
This also means that Pow users can now Forward all of their Pow apps with one command:
forward dev. If your Forward URL is somecompany.fwd.wf, and you have a Pow app running at someapp.dev, you’ll be able to view it at someapp.somecompany.fwd.wf. NOTE: this will expose all of your Pow apps via the same Forward tunnel, which is probably not a good idea. We’d recommend Forwarding your Pow apps individually, like so:
Let us know if you have any trouble.
—The Forward Team
January 4th, 2013
Forward launched with support for password-protection. Each time you started a Forward, you could use the
--auth option to set a username and password that would be required to open the Forward URL in a web browser. This worked great for occasionally password-protecting your Forwards, but could become tedious if you did it everyday.
So, we’ve added a new feature to make it more convenient for our customers who use password protection frequently. If you log in to forwardhq.com and click Preferences, you’ll find a new option to “automatically password-protect my Forwards”. With it enabled, you can leave off the
--auth option when you start a Forward, and it’ll automatically use the username and password that you’ve set in Preferences.
If you’d like one of your Forwards to have a different username and password, you can still use the
--auth option, and your Forward will use the username and password you provide instead of the default. And if you’ve set a default, but still want to create some non-password-protected Forwards, just use the
--no-auth option when starting one.
Finally, many of our Business and Small Business customers work on secret projects for their clients. In those cases, it could be a big issue if a developer were to forget to password-protect their Forward and it leaked to the public. In order to prevent this, Business and Small Business customers will find a second option in Preferences to “require all Forwards to be password-protected”. Enabling this will make it so that all Forwards will require a username and password (either the default, or set with the
--auth option) to view them.
November 29th, 2012
After we sent out the first month’s email invoices, we got some requests for “real” invoices, particularly from our European customers.
Well, today we’ve launched real invoices. We’ll still be sending the same billing emails, but we’ve added some new stuff to the Billing section of your account on forwardhq.com. Now you can view a full version of each invoice, as well as all of your past invoices.
Also as a part of the new invoice feature, we’ve added a company name field for all accounts. For new customers: the field has been added to the sign up form. For existing customers: you should go set yours in the Account section on forwardhq.com before your next billing cycle. The account email address will be used as the the company name until you change it.
Finally, we’ve also added an “invoice notes” field under Billing, where you can add other information that will appear on your invoices beneath your company name, e.g. your address, VAT number, etc.
We hope you find the new invoices useful!
October 22nd, 2012
When we launched, all Forward URLs had a two-part subdomain: the first part being random characters, and the second part being your company’s suffix (e.g. fq3o-yourcompany.fwd.wf).
This is different from how subdomains behaved when using Showoff (Forward’s predecessor). With Showoff, an unlimited plan allowed you to choose a subdomain (e.g. yourcompany.showoff.io). And whenever you started a Showoff tunnel, you got that same subdomain every time, without having to pass in any extra parameters.
While building Forward, we switched to the two-part subdomains so that all users in a Business or Small business account could share a company name suffix. Initially, we decided to make Solo accounts also work this way so that everything would be consistent. However, this meant that for Solo account users, there was no way to get a simple subdomain like you could get with Showoff.
Well, our customers have spoken (enough of you to make us rethink our decision), and today we rolled out a change to Forward that makes Solo accounts work the way Showoff used to: when a Solo account user starts Forward, they’ll get the simple subdomain (e.g. yourcompany.showoff.io) by default—no random prefix, and no need to specify a custom prefix.
This change does not apply Business and Small Business accounts. These account types have multiple people using them at once, so it could become a nightmare for people trying to “claim” the simple subdomain, or trying to figure out who is using it at any given moment. We’re considering a few ways to handle this situation in the future, but for now we’ve intentionally omitted this feature in the interest of avoiding all the headaches.
October 18th, 2012
Since the initial launch, we’ve received lots of helpful feedback and feature requests for Showoff (Forward’s predecessor) on twitter, via email, and especially through UserVoice.
Here’s a selection of major customer-requested features that we’ve included in Forward:
This is a big one. Forward lets you have a single business account with multiple users, so now everyone in your company can use Forward without having each person billed individually. Besides simplifying billing, this also lets everyone in the company create Forward URLs that are suffixed with the company’s Forward subdomain.
Optional User-Specified Subdomain For Each Forward
Now, whenever you start Forward, you have the option to enter a custom subdomain for your Forward. A non-random Forward URL helps prevent confusion when you’re juggling a few of them at a time. It’s also nice to be able to give your Forwards descriptive names, so people know what they’re clicking when they get a Forward URL from you.
Custom Placeholder Page For When A Forward Isn’t Running
When you give someone a Forward URL, normally they’ll be able to access it until you stop the Forward. But sometimes you need to shut down your computer, or close your laptop and carry it somewhere.
In these cases, when your computer isn’t connected to the internet, people who visit your Forward URL would see an error message saying your Forward wasn’t found. Previously, if someone tried to visit one of Forward URLs they’d see a generic error message. Now, you can supply your own (branded) HTML error page that tells visitors that your Forward is temporarily offline.
We’re always looking for ways to improve Forward, and we’d love to hear your suggestions. Let us know @forwardhq on Twitter.