Here at Follow My Vote, we rely on WordPress to host our website. We are an online company, so this website is our public face and we strive to keep it informative and attractive to guests. But that isn’t always easy. In order to keep a WordPress website secure and reliable, both WordPress itself and all of the plugins must be kept up to date, but sometimes updates cause breakage to the website that can impair its visual appeal or even result in downtime, leaving us scrambling to get all of the pieces we need working together again with the new version. Furthermore, sometimes we want to update the content of the site, and if it’s a small change, it’s (usually) easy and safe to just push it into production immediately. Still, sometimes we want to make big changes and see those in action ourselves before taking them live to show to the world.

In other words, when talking about making changes to the website, whether those be updates, new content, or whatever else… we want to try it before we buy it. We want to see it and try it out like it’s for real, but the public still sees our stable and reliable site while we tidy and polish the next version behind the scenes. And of course, it needs to be easy to set this up without asking our content creators to jump through complex technical hoops.

What we really want is a way to create a staging copy of our website, that we can make changes to and test out new content or configurations with, while the production website is all that is visible to the public eye. Well as it turned out, that wasn’t quite as easy as we expected…

What We Tried

One may suppose that the easiest solution to a problem is the best, so the most obvious thing to try was the features built into WordPress for making drafts of posts and pages. And indeed, these features are great for new content, and they’re reasonable for updating old content, but we find them best suited for quick and basic changes. They can be a bit clunky when doing certain kinds of edits or design changes, and it always feels a bit too easy for a stray click or keypress to publish a draft before it’s ready. For a lot of content work, we find ourselves wanting a bit more, and furthermore, these features leave us completely in the cold for testing updates before we commit to using them on our production website.

So we needed a stronger solution than we found built into WordPress itself. The next thing we tried was to simply copy the WordPress installation and host it on a staging domain, meaning we put the staging site on staging.followmyvote.com rather than regular followmyvote.com and made our updates there.

This was a quick and dirty solution that required minimal sophistication to get up and running, but the problems it created were endless. First of all, this is not particularly discreet. Anyone could type in staging.followmyvote.com and see what we’re up to. There are ways to put it behind a password, but it still feels a bit unprofessional to have this internal resource discoverable to the public, even if it is difficult to guess the password to see inside. Secondly, WordPress doesn’t take kindly to being hoisted up from one domain and plopped down on another. The website needs configuration changes to make it OK with that, and while those are relatively easy to do, it complicates the process, making it a less attractive solution.

We then realized that even if you make WordPress itself work when hosted on a new domain, the pages don’t. Lots of pages had hardcoded links to followmyvote.com rather than relative links based on the current domain, and it was difficult to train ourselves not to copy and paste links without removing the domain from the beginning of them. This made working on the staging site error-prone, and often resulted in us clicking a link that took us back to the public site without our realizing it, which could then lead to making changes there unintentionally! Furthermore, when we eventually did deploy the staging site into production, we realized to our chagrin that we had accidentally copied quite a number of links to the staging site into it, which was a rather embarrassingly public mistake.

All around, then, the approach of using a separate staging domain was painful, error-prone, and ridiculous. It was fraught with difficulties and risks, making it easier to do it wrong than to get it right. The failures of this approach made it far worse than if we had not attempted to use a staging site at all. I considered the possibility that with automation and filtering, we might be able to rescue the strategy, but quickly decided that this would be risky and complicated and would doubtlessly result in still more mistakes.

Nevertheless, I remained convinced that the staging site idea had merit, and for a few years, I contemplated what I would want from such a solution and how it could be done.

A Solution Begins to Take Shape

The first step to solving a problem is always figuring out what one would want in a solution. In the case of a staging solution for our website, I wanted the following features:

Same Domain First and foremost, the staging site and the production site must share the same domain (and URL). No more staging.followmyvote.com nonsense, no more reconfiguring WordPress for different domains, and no more changing links back and forth. Both sites must be accessed by browsing to followmyvote.com.

Not Just WordPress The solution must be built outside of and around WordPress, not using a plugin or any other feature of WordPress. Building such a solution into WordPress would be inherently more complicated than building it outside, and it wouldn’t provide the kind of isolation we would need to test different versions of plugins, themes, or WordPress itself without jeopardizing the production site. Moreover, I want a solution that works for other sites and site frameworks; not merely WordPress.

Professionally Discreet The existence of the staging site must not be publicly obvious. Our public web presence should be buttoned up and shouldn’t have technical details exposed. It should not be feasible for any passerby or bot to access the staging site, even if they happen know it existed. On the other hand, it should be relatively convenient for us to share access to it with others, without expecting them to possess unusual knowledge or dedication.

Zero Downtime Copying the production site into a new staging site, and subsequently deploying a stable staging site into production, should both incur zero downtime. The website should remain up and serving users the entire time with the only public indication that something happened being a change in content.

Straightforward Automation While it is true that a good staging solution will be reasonably convenient to operate manually, it should also be straightforward to implement full automation in the future so that staging sites can one day be configured, spun up, deployed, or retired with a simple back-office control interface.

The Path Comes into Focus

With these requirements in mind, I put on my sysadmin hat and considered our existing deployment infrastructure. Follow My Vote runs a public WordPress site as well as several internal cloud services to facilitate our business operations. All of these exist as containerized microservices in Docker utilizing Traefik as a TLS-terminating reverse proxy sitting in front of these services. This seems to be a typical deployment strategy, and it has worked well for us for years with minimal turbulence after the initial learning curve.

When we tried the staging domain, we just deployed a copy of WordPress with Traefik serving it on the staging domain rather than the primary domain. While easy to implement, this strategy failed due to the difference in domain. In theory, however, the same back-end architecture could be used successfully if instead of using the domain to route traffic between the production and staging back-end services, I used some other discriminant.

My first idea was to use client IP to select between serving the production and staging sites; however, I rejected this approach because it was clumsy and complicated. On the one hand, an IP address isn’t a good identifier of a client anymore due to NAT, and on the other, it makes the Traefik configuration annoying due to frequent updates to an excessive number of rules.

Then I considered that if the browser indicated that it was looking for the staging site in its request, this would also be adequate for Traefik to pick out and decide how to route the request. This was the approach I finally settled on: the client inserts a custom header into its request and Traefik determines whether the header is correct and, if so, routes the request to the staging back-end.

There was one wrinkle in the solution. WordPress sites regularly make requests to themselves, and since WordPress just does a DNS lookup for the domain it’s configured to run on and sends the request there, obviously without our fancy custom header, the staging service’s requests get routed to the production service rather than back to staging! Working around this required a bit of ingenuity, and I’ll cover it in the technical guide below.

This solution was highly successful for us. It’s easy and reliable to implement on the server side, and opting in or out of the staging site is completely client-side. A browser plugin can handle the injection of the header, and plugins exist for major browsers to configure a custom header and to enable or disable the header with a click, making it convenient to switch back and forth between production and staging. Staging environments can be kept private by making the value of the header into a password. If a staging environment is desired to go live, simply remove the custom header requirement from it and give it a higher priority than the production server, and Traefik will switch new traffic to it with zero downtime. The custom header strategy also looks like it will be easy to automate, although for the time being, this is still future work.

OK, now it’s time for the fun part.

How To Run It on Your Server

We show the setup of this staging solution in three stages. First is the foundation stage, where we set up a trivial Traefik reverse proxy and a placeholder webpage hosted by a fallback server, used when nothing else is working. Initially, no other servers will be defined, thus nothing else will be working and therefore the placeholder will be shown. The second phase adds our production website on top of the placeholder, and the third phase adds a staging site on top of that. We will explore the configs used in each of these phases here, but readers can also see the full config directory hierarchy in a git repository where each phase is represented by a commit. The git repository is at https://gitlab.followmy.vote/nathanielhourt/staging-site

The Foundation

We will be using Docker Compose to deploy our server infrastructure. Installing Docker and Docker Compose is left as an exercise for the reader; there is an abundance of tutorials easily discoverable online for virtually all imaginable servers and environments. The reader also must choose a domain on which they wish to host their website and set up DNS for it. If it is not convenient to set up public DNS to follow this tutorial, an entry into a client’s /etc/hosts file will suffice, but in this instance the reader must procure their own TLS certificate and manage it manually. Configurations for both manually managed certs and automatic Let’s Encrypt certs (for deployments on public domain) are shown below.

OK, with Docker and Compose ready to go and either a public domain or a cert for our private domain in hand, let’s write our service configuration. Begin with a new directory to contain the servers on this website, and within it, a subdirectory for the foundation of our deployment, which will hold configs for Traefik and the placeholder site. In this tutorial, we’ll call these directories mywebsite and foundation. In the mywebsite directory, let’s make a file of environment variables we may share with the various services in our deployment, called env. The only variable we need here for this tutorial is the domain upon which we’re hosting our website:

mywebsite/env

DOMAIN="stagingsite.followmy.vote"

In our foundation directory, we’ll add a compose.yaml file, and Docker Compose will look for environment variables in a .env file in the same directory as the compose.yaml file, so make a symlink at mywebsite/foundation/.env to the shared environment file, ../env.

Now let’s explore the contents of the compose config section-by-section, and remember that the full config of this phase is visible on the repo.

We begin by defining a Docker network (which is to say, a VLAN) to interconnect our production services.

mywebsite/foundation/compose.yaml

networks:
  prod:
    name: production-vlan
    ipam:
      config:
        - subnet: 172.100.0.0/24
          ip_range: 172.100.0.128/25

This creates a network, which we can refer to in this file as prod, but which will be known as production-vlan outside this file. That network will occupy the 172.100.0.0/24 subnet, but the first half of the subnet will be reserved for static IPs and Docker will only assign IPs dynamically out of the second half of the subnet.

Next, let’s make a service that will be Traefik, using the official public Traefik image for it, tracking the 3.1 series:

mywebsite/foundation/compose.yaml (cont’d)

services:
  traefik:
    image: traefik:v3.1
    networks:
      prod:
        ipv4_address: 172.100.0.10
    ports:
      - "80:80"
      - "443:443"
    restart: always
    healthcheck:
      test:
        - CMD
        - traefik
        - healthcheck

We assign our Traefik service the fitting (if not very original) name traefik and put it on our prod network with a static IP. Note that we’re only dealing with IPv4 in this tutorial, but Docker will invisibly forward inbound IPv6 traffic to IPv4 service networks if desired. Of course, readers may define IPv6 addresses for their services at their discretion.

We also bind the host’s ports 80 and 443 to the same ports on the service. Note that the ports section governs public ports belonging to the host system — these are not private ports on the VLAN we created! We are giving the Traefik service access to bind the host’s ports 80 and 443, and this is the only service to which we will grant direct access to public ports. All other services will have private VLAN networking only, and Traefik will forward traffic to them over said VLANs as appropriate.

We direct Docker to restart the Traefik service if it stops for any reason, and we define a healthcheck command that Docker will run regularly to verify that Traefik is healthy. Note that by default, Docker will take no corrective action if it becomes unhealthy, but it makes for pretty status reports.

Finally, let’s attach some volumes to our Traefik service. Docker containers, by default, have no persistent storage, and all the data they store is subject to be reset to the original image’s contents any time the service restarts or is rebuilt (NB, during normal maintenance). Docker Volumes allow us to persist paths within the container, and also give us a way to place specific files and directories into the container or share certain files or directories from the host with the container.

mywebsite/foundation/compose.yaml (cont’d)

    volumes:
      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
      - type: bind
        source: ${PWD}/volumes/certs
        target: /etc/certs
      - type: bind
        source: ${PWD}/configs/static.yml
        target: /etc/traefik/traefik.yml
        read_only: true

Here, we have done all three. We share the host’s Docker socket with the container, allowing Traefik to access Docker’s API, we make a persistent directory wherein Traefik can store (or access) TLS certificates, and we mount into the container Traefik’s config file which we will have created by the time we start this service and Docker goes looking for it.

Note that when we give Traefik access to Docker’s API, we give up all the security benefits of containerization, at least in Traefik’s case. Having access to the Docker API bestows the full power of the host’s root account. Those concerned about this can look into options like rootless Docker or podman and can still follow this tutorial, but details on how to set this up are out of scope here, and the benefits are questionable: either way, a successful attack on Traefik will compromise everything Docker has access to, and whether this equates to the host’s root or not, it’s probably still everything of value on your server. It would be nice if there were a way to expose a restricted Docker API to Traefik instead of the full gamut, but I am not aware of a way to do this today.

Pressing onward, we define a second service in this compose file, which is our placeholder website. We name the service greeter and assign it a bare nginx image. Attach it to our prod network with no config, and Docker will assign it a dynamic IP automatically. We’ll also mount in the website to host, although for this tutorial this is merely a single config file.

mywebsite/foundation/compose.yaml (cont’d)

 greeter:
    image: nginx:latest
    networks:
      prod:
    volumes:
      - type: bind
        source: ${PWD}/configs/greeter.cfg
        target: /etc/nginx/conf.d/default.conf
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.greeter.rule=Host(`$DOMAIN`)"
      - "traefik.http.routers.greeter.priority=1"

At the end, we include a section of labels. These are simple key-value pairs that can be attached to most constructs in Docker, and while Docker itself doesn’t use or care about them, they provide information that systems integrated with Docker (such as Traefik) can use to determine how to handle things running within Docker. These labels are how we tell Traefik how to host our service, and Traefik monitors Docker for services starting and stopping and consults the labels on those services to automatically update its routing according to the services available at the moment.

On our placeholder service, we put a label that tells Traefik that we want it to proxy for this service, another label telling Traefik what traffic this service is intended to host (in our case, traffic addressed to our domain), and finally, a label setting a very low priority for this service, so that of the requests that are addressed to our domain, Traefik will only forward those requests to the placeholder if nothing else is available to take it. Initially, since no other service is running, this will show us that our servers are working properly. In the next phase, when we start our real website, however, this placeholder will no longer be served unless the server of our real website crashes. This is because the real website server has a higher priority, granting it precedence over the placeholder server any time both are available.

OK, that’s our entire services config. Now let’s make the other things we need for our servers. Create a directory at mywebsite/foundation/volumes and a certs directory within. Next, create also a directory mywebsite/foundation/configs, and within, we’ll make two config files, one for Traefik, and one for our placeholder nginx website.

The nginx config is trivial:

mywebsite/foundation/configs/greeter.cfg

server {
    listen       80;
    listen  [::]:80;

    location / {
        add_header Content-Type text/plain;
        return 200 "This website is currently under construction. Check back later for total awesomeness! =)\n";
    }
}

Note that we listen only on port 80. No TLS is used within the VLANs; Traefik terminates the TLS and proxies raw HTTP traffic to the services. This way the services need not deal with certs or TLS options at all, simplifying their configuration immensely without exposing unsecured traffic to the internet. All of the TLS and certificate concerns can be handled centrally at Traefik.

Next, the Traefik config. I’ve included comments to elucidate inline, but we’ll discuss in more detail below:

mywebsite/foundation/configs/static.yml

# Define the ports Traefik listens on
entrypoints:
  # Listen on port 80, but by default just serve a 301 redirect to the same URL on HTTPS
  web:
    address: ":80"
    http:
      redirections:
        entrypoint:
          to: websecure
          scheme: https
  # Listen on port 443, and set a default certificate to use so services don't need to configure it individually
  websecure:
    address: ":443"
    asDefault: true # Since web is just a redir to websecure, make all routers default to using only websecure
    http:
      tls: {} # Set a default here for all routers using this entrypoint to use TLS; simplifies per-router config
      # When using Let's Encrypt, uncomment this line as well as the definition of the resolver below
      # Then you can remove the manual certs config from the providers section below
        #certResolver: letsencrypt

# Define a certificate resolver. Traefik uses Let's Encrypt by default, but we need to configure it to make it work
#certificatesResolvers:
#  letsencrypt:
#    acme:
#      email: "your@email.here"
#      storage: /etc/certs/acme.json
#      keyType: "EC256"
#      tlsChallenge: {}


# Configure Traefik to watch for docker services to show up asking to be hosted
providers:
  docker:
    watch: true
    # Matter of taste; I like to explicitly set which services Traefik should expose via the traefik.enable=true label
    exposedByDefault: false
  # During testing, using Let's Encrypt can be difficult, so we can manually configure cert in a dynamic config file
  file:
    filename: /etc/certs/manual.yml

# Enable the ping API endpoint, so docker can do health checks
ping: {}

### The rest of this is optional stuff that might be useful from time to time

# To enable Traefik's dashboard website and API
#api:
#  dashboard: true
#  insecure: true # To allow simply querying Traefik's port 8080 rather than needing to define a router to get to it

# To log each request like a webserver does
#accessLog: {}

# To increase logging verbosity and make it easier to diagnose problems
#log:
#  level: DEBUG

Traefik operates with two classes of configuration. The first is the static config, which is what we’re setting here, and it controls the constant concerns that are the same over an entire execution cycle of Traefik. The second configuration class is the dynamic configuration, which controls the services Traefik is expected to expose and the rules controlling how those services are accessed. The dynamic configuration changes over the course of Traefik’s execution, and Traefik constantly adjusts its behavior to align with this configuration: as new services show up or old ones shut down, Traefik updates its routing and adjusts how requests are directed accordingly. The dynamic config comes from “providers” which Traefik monitors for up-to-the-moment status updates and changes, and the providers Traefik should monitor are defined in the static config.

OK, with that context established, let’s look over the static config above. First, we define entrypoints. These are the ports Traefik should listen on for incoming traffic. We configure two: port 80, for HTTP traffic; and port 443, for HTTPS. We name the HTTP entrypoint web and the HTTPS, websecure. We configure Traefik not to connect HTTP traffic to services, but rather to respond with a 301 redirect to HTTPS. This is, of course, a matter of preference, but it’s a common enough pattern that it’s useful to show it here. We configure the HTTPS entrypoint, websecure, to be a default entrypoint, to simplify the per-service configuration, and we set TLS options so as to inform Traefik that this entrypoint deals with TLS traffic, as it will not infer this from the use of port 443 alone.

In the next sections, the config is different for those wishing to use a public domain and Let’s Encrypt certs than for those configuring their certs manually (as those using a private domain must do). Certificates are a dynamic concern (they change at runtime), so they aren’t set in the static config, but where to get them is. If configuring the cert manually, just put an empty tls config block to indicate that TLS is used, but to accept the defaults. We’ll then set a dynamic config provider that loads in the certs. Alternatively, if using Let’s Encrypt, uncomment the certResolver config so Traefik knows to get certs automatically, as well as the config lines defining the certificate resolver to be used. In this case, the dynamic configuration provider for manually managed certs can be omitted.

Moving ahead to the providers configuration, we configure Traefik to monitor Docker for dynamic configurations, and I prefer to select explicitly which services should be exposed with the traefik.enable=true label, but again, this is a matter of taste. Then, for those managing certs manually, we add a dynamic provider from a file, where we will hook in those certs.

Those using Let’s Encrypt can omit this, but for those who aren’t, here are some typical contents of that dynamic config file. Be sure also to put in your private key and certificate files alongside so the paths provided in the dynamic config point to them in the container’s filesystem (remember that our mywebsite/foundation/volumes/certs directory shows up at /etc/certs inside the container!).

mywebsite/foundation/volumes/certs/manual.yml

tls:
  stores:
    default:
      defaultCertificate:
        certFile: /etc/certs/followmy.vote.pem
        keyFile: /etc/certs/followmy.vote.key.pem

Returning our attention to the static config, hopefully the remainder of the configuration is self-explanatory. I do want to note, however, that the ping section is only needed if using the healthcheck on the Traefik service in compose.yaml. If no healthcheck is required, the ping section can be omitted as well. To opt into anonymous usage statistics collection, add a global section with a setting sendAnonymousUsage: true.

With that, our foundation is complete! Go ahead and start the servers by setting your working directory to foundation and running docker compose up. Note that this starts the servers in the foreground with logging to the console; to daemonize it all, pass an additional flag -d and monitor the status with docker compose ps and docker compose logs. You should now be able to open your website in a web browser, though if using Let’s Encrypt, it may take a few extra moments for the cert to be provisioned. If automatic certs don’t seem to be working, turn on the debug logging in the static config and monitor Traefik’s output for details on the ACME negotiations. The certs that Traefik has acquired go into acme.json in the certs volume — that file can also be monitored to determine whether certs are being issued successfully, without enabling debug logging.

Take a few moments to bask in the glory of your new foundational website infrastructure… and then move on to Phase II, the production website.

Pushing to Prod

The simplest phase of our deployment, now we create the production website. For our demo, this is a trivial single-page website, almost identical to the fallback site. We just create another bare nginx service and populate it with a slightly different config. In a real deployment, you might set up a WordPress here or any number of other apps; from the perspective of the staging system as well as Docker and Traefik, it’s all fundamentally the same.

As an aside, if you are setting up an app with dependencies, and those dependencies are in their own containers, I recommend putting these dependencies on a separate VLAN without Traefik and connecting the front end to both the prod VLAN and its support VLAN. This creates a better separation of concerns. If your front end is on multiple VLANs, you need to add another label to it so Traefik knows which VLAN to connect to it on, i.e. traefik.docker.network=production-vlan (remember to use the absolute name, not the local alias).

But back to our demo, let’s begin by creating a new directory mywebsite/production, and in that directory creating our .env symlink back to ../env. Next, create our compose file with our service definition:

mywebsite/production/compose.yaml

networks:
  prod:
    name: production-vlan
    external: true

services:
  website:
    image: nginx:latest
    networks:
      - prod
    labels:
      traefik.enable: true
      traefik.http.routers.prod.rule: "Host(`$DOMAIN`)"
    volumes:
      - type: bind
        source: ${PWD}/configs/website.cfg
        target: /etc/nginx/conf.d/default.conf

We don’t need to define the network this time, as it was already defined in the foundation configs. This time we just give it a local name, mention its absolute name, and set external to true so Docker knows to find it already created rather than creating it anew.

Then we create our service, essentially the same as before, but this time we don’t set an artificially low priority. I used a different syntax for the labels this time… but both formats do the same thing.

Finally, we create our nginx config:

mywebsite/production/configs/website.cfg

server {
    listen       80;
    listen  [::]:80;

    location / {
        add_header Content-Type text/plain;
        return 200 "Welcome to Follow My Vote's staging website demo. You are currently viewing the production site.\n";
    }
}

To launch it, we do the same thing as before. Make sure Traefik is still running and, from the new production directory, do a docker compose up -d to start the website in the background. Now go to your domain in your browser, and you should see the new production page rather than the placeholder.

And with that, we’re ready to make our staging site!

Staging the Next Thing

Now to launch our staging site, we could actually just copy our production site, tweak the Traefik rule, and be done… except that if your website or app is anything more than a trivial static webpage, it might at some point want to connect to itself as a client (for example, I know for a fact that WordPress does this to trigger background tasks) and if we are too naive about how we set this up, the staging service won’t connect to itself but will rather connect to the production service. This is because the staging service doesn’t know to set the magic header needed to reach itself through Traefik.

This posed a bit of a conundrum for me when I was designing this solution. I couldn’t just convince the app (I was working with WordPress) to connect to localhost (its own container) rather than using DNS to find Traefik because while it was configured to serve over port 80, it was also configured to know that its URL uses the https:// scheme, so it used that and thus couldn’t connect to itself directly — it had to go through Traefik for TLS termination. “OK,” I thought, “but I control the IP of the container, so I can just tell Traefik to route the request-to-self based on source IP, right?” Well, no, because the way Docker routes outgoing traffic, all containers’ outgoing traffic to a public IP address gets NATed together and shares a single source IP. So I have to force my app to connect to itself through Traefik, but also within Docker without going to the public IP associated with my domain on public DNS. Here is how I did that.

We create a new VLAN for the staging site, giving it a different subnet from the production VLAN. We then put Traefik on both VLANs, giving it an alias on the staging VLAN which is our domain. This means that when a container in the staging VLAN does a DNS lookup on our domain, Docker sees that this is an alias for a container on the VLAN and gives that container’s VLAN-private IP as the DNS result, rather than the result of a public DNS query! This causes the staging container to connect to our domain by connecting to Traefik directly over the staging VLAN, thus eliminating NAT and showing its real source IP to Traefik. Traefik is then configured to route any and all traffic destined for our domain coming from the staging VLAN to the staging frontend, even if it doesn’t have the magic header that says “route me to the staging service”!

So first things first, we edit our foundation compose config to add the new network and to give Traefik an alias on it. In the networks: section, we add:

mywebsite/foundation/compose.yaml (insert)

 staging:
    name: staging-vlan
    ipam:
      config:
        - subnet: 172.200.0.0/24
          ip_range: 172.200.0.128/25

Then in the services.traefik.networks: section, we add:

staging:
        ipv4_address: 172.200.0.10
        aliases:
          - $DOMAIN

Remember that you can see the entire config diff on the git repository.

Next, we just copy our entire production directory calling the new copy staging and update all the references to production things to refer to staging things instead, and we update the Traefik routing rule for the staging service like so:

traefik.http.routers.staging.rule: "Host(`$DOMAIN`) && (Header(`X-REQUEST-STAGING`, `Saex6Bu0`) || ClientIP(`172.200.0.0/24`))"

Note that we changed the label key as well as the value; the prod or staging in the label key are names that we define arbitrarily, and they must be globally unique. This is true in many of Traefik’s service labels, so copy and paste carefully!

Examining our rule, it now applies to traffic destined for our domain AND either bearing the magic header, or coming from our staging VLAN subnet. Also, by default a Traefik routing rule’s priority is equal to the number of characters in the rule (a cheap but remarkably effective heuristic for preferring more specific rules over less specific ones), meaning that while our staging traffic will match both the production rule and the staging rule (and the fallback rule too!), the staging traffic will be routed to the staging service by virtue of that service having the longest rule.

Make the appropriate changes to the staging site by updating its config, and we’re ready to run the staging site live! With yet another docker compose up -d we can make it so.

To access the staging site, it is necessary to set a custom header in our requests to our server. An easy way to do this is via the use of the Modify Header Value extension for popular browsers. Go ahead and give it a whirl! (Users of Chromium-based browsers may need to use ModHeader or some other option instead, as Chromium’s Modify Header Value doesn’t seem to work on all requests that match the filter).

Our staging site is now live and working, discreetly, for only those we want it to. We now can make our desired changes to it, and test them out as if they were in prod, on the normal domain and with the normal config. From an application perspective the staging site is exactly identical to the production site except that only we can see it, and only when we want to, while the rest of the world sees the production site without bothering to know any other option might exist.

In fact, the staging site is so similar to the production site that when we decide it’s ready, we can simply make it the production site — at least temporarily.

Zero-Downtime Updates

To deploy the new staging changes into production, we could shut down production, copy over the new changes, and re-deploy, and with the help of our fallback server we could even display a friendly “Scheduled maintenance” page in the meantime… but wouldn’t it be nicer if we could just switch over with no downtime at all? Well as it happens, there are a number of ways to do this. One of them would be to simply relaunch the staging site with a routing rule that makes it preferable to the production site for all traffic. With a health check on it, Traefik will watch it until it reports as healthy after its startup routine, and then switch new traffic over to it because it has a preferable rule. Once traffic switches over, we could shut down the production site, update it to the new code, start it up again, and once it’s healthy, shut down the staging site so traffic goes back to the service labeled as production. Voila! An upgrade with no downtime at all!

Of course, this isn’t the only way to accomplish the same result, and all such mechanisms have advantages and disadvantages, and depending on the exact details of your app, this approach may not work and possibly no zero-downtime approach will work at all. Nevertheless, this approach should work for many applications, and even if the zero downtime bit doesn’t work for your particular app, this overall strategy should be effective and compelling.

I wish you luck and I hope you’ve enjoyed this tutorial. If you get this far, or if you have any questions or trouble, drop me a line on Matrix: @I:nathaniel.land. I’ll see you around! =)

Read More Articles From The FMV Blog

The post WordPress Staging Website on the Same Domain appeared first on Follow My Vote.

Solana

Solana is a rather new open source project, launching officially in March 2020 by the Solana Foundation, headquartered in Geneva, Switzerland. The project competes to provide decentralized finance (DeFi) solutions contending against platforms like Ethereum. 

Solana (SOL) uses a unique hybrid consensus model. Proof-of-history (PoH) is combined with the proof-of-stake (PoS) to reach consensus on the blockchain. Proof-of-stake has been used by many other projects, but proof-of-history is a bit more noteworthy. PoH uses a verifiable delay function (VDF) to assign timestamps on the blockchain in a decentralized manner. Ethereum, by contrast, uses outside programs to assign a timestamp so transactions can be validated in the order they were received. On Solana, this forces block producers to go through the VDF to get to their assigned slot and produce a block. On the Solana chain, data is inserted into the sequence by appending the hash of the data of the previously generated states. The state, input data, and count are all published. This creates an upper bound on time and since PoH can reference a previous hash, the lower bound time is also known. Therefore the VDF will indicate the exact time of any transaction. This entire process is important because it allows the Solana chain to speed up transaction speed. Since everyone knows the exact time, validation can be completed much quicker. Solana now has the capability to process up to 50,000 transactions per second. 

Solana’s future looks bright with their Proof-of-history innovation. They also boast low fees and a growing marketplace for NFTs. 

Bitcoin Cash 

Bitcoin Cash was created in 2017 as a result of concerns about the scalability of Bitcoin. Developers and Bitcoin influencers could not come to terms on the best way to scale the blockchain. Some supporters pushed for the Segregated Witness update while others called for scaling onchain by increasing the block size. A hard fork occurred and two blockchains emerged, one called Bitcoin and one called Bitcoin Cash. 

Bitcoin Cash is the project that chose to scale onchain, and is considered by many to be the continuation of the original Bitcoin project as peer-to-peer electronic cash. Bitcoin moved on with SegWit which has been described as inelegant and complicated, creating two parallel sets of rules for evaluating transactions, but ignoring one of them. SegWit technically breaks Bitcoin’s security by empowering miners and anyone who can coerce them to steal balances. according to the Bitcoin protocol, all segwit transactions can be spent by anybody with no proof of authorization. That means that literally anyone can make a transaction that spends the bitcoins in a SegWit address. The “witness data” (which is the rules for who’s allowed to claim the outputs, and the proof that the rules were followed on the inputs that claim the outputs) is moved out of the main block and replaced with a simple “anyone can spend me, there are no rules and no proofs,” and it’s up to miners to know what the rules really are, ignore the “anyone can spend me” instruction, and instead apply the rules from the witness data. Even so, Bitcoin has continued to gain popularity and value, dominating the cryptocurrency space. 

Bitcoin Cash (BCH) has not experienced the same rise as Bitcoin, but has been innovating nonetheless. The principal goal of Bitcoin Cash is to provide more economic freedom to those who need it in the world. In this regard they have been making strides. These include advancements to the blockchain such as introducing Schnorr Signatures, the implementation of a token standard called SLP, and a new difficulty algorithm. Bitcoin Cash has also been successful assisting communities in countries like Argentina, Venezuela, and South Sudan. Flipstarter is another exciting project for Bitcoin Cash. The project is a noncustodial crowdfunding tool that uses BCH. This tool empowers the community to use its own means to fund valuable projects for the BCH environment. Bitcoin Cash is also making moves with regard to institutional investment. Greyscale is now offering shares of the Bitcoin Cash Trust to institutions allowing institutions to disregard custody concerns. A new fungibility protocol directed at obscuring transactions on the BCH chain called Cashfusion was implemented, which is a big step forward for privacy. A whopping $3.2 billion has been anonymized via Cashfusion. Lastly, Bitcoin Cash is now a competitor in the decentralized finance (DeFi) space. General Protocols launched Anyhedge and Detoken, which are two new DeFi tools designed to operate on top of the BCH protocol.

Avalanche

Avalanche (AVAX) launched it’s mainnet in 2020 and has grown leaps and bounds in 2021. The project  is a layer one blockchain that focuses on decentralized applications and custom blockchain networks. Avalanche is competing directly with Ethereum in the smart contract space and hopes their higher transaction output will give them competitive advantage. (TPS is upwards of 6500 currently) 

What makes Avalanche special is their use of three interoperable blockchains to achieve true decentralization at scale. The three chains are the Exchange Chain (X-Chain), the Contract Chain (C-Chain), and the Platform Chain (P-Chain). The X-Chain serves as an exchange for the AVAX tokens and other assets on the chain. This blockchain is run by the Avalanche consensus mechanism. This mechanism works to allow all nodes to process and validate transactions by enlisting a directed acyclic graph (DAG) protocol. By doing this, transactions are processed simultaneously, and validators can be statistically certain transactions are correct via their random polling. The C-Chain exists to run smart contracts and dApps. This chain includes the Avalanche Virtual Machine giving devs the ability to fork Ethereum Virtual Machine compatible dApps. The C-Chain is operated by the Snowman consensus mechanism, which is the implementation of the Avalanche consensus protocol for linear chains. The final blockchain in the trifecta is the P-Chain. This chain coordinates the network validators and controls subnets. Subnets are sets of validators. The P-Chain also runs on the Snowman consensus mechanism. 

We commend Avalanche for their continued development of blockchain bridges, which allows the transfer of data between two different blockchain projects.

This completes our blockchain highlights post for 2021.

DISCLAIMER: We do not endorse these projects; we are simply recognizing that these groups have made significant innovations in the blockchain space. Use our contact form if any info about these projects needs updating and/or if there are any new innovations in the blockchain or open source fields Follow My Vote should be made aware of.

The post 2021 Blockchain Highlights appeared first on Follow My Vote.

We encourage our fans and supporters to watch and share the video!

At one point in the podcast, Chris asks about the obstacles we face when considering the trust of users and security of the platform. Follow My Vote CTO, Nathaniel Hourt, gives a thorough explanation of the 3 main concerns we are addressing on this front. Be sure to watch the interview all the way through so you don’t miss it!

You can see other videos in the series on the ChrispBTC YouTube Channel. ChrispBTC plans to interview other companies concentrating on blockchain voting and he is even inviting politicians (for and against) to be on the show.

The Follow My Vote team is open to participating on other podcasts and interview opportunities. If you run a podcast and would like to have us on or have a suggestion for a show that you think would be a good fit, please reach out through our contact form.

The post Answering The Tough Questions On A New Blockchain Voting Podcast Interview appeared first on Follow My Vote.

As we are researching and developing new platform technologies necessary to someday support the development of online voting systems, we take note of others in the industry working toward such systems; especially those also using blockchain technology.

One such company is Voatz, and today I’d like to highlight their efforts and share some thoughts about their work. Let me preface this by saying that this is just one man’s opinion and perspective. I have no affiliation with Voatz, and have not closely examined their work. My words here should be viewed merely as the casual commentary of an interested bystander.

Voatz is working on solutions for an online voting app using blockchain as a durable record of the election procedures and results. They are developing the procedures and workflows necessary to conducting an online election, and creating the tools and interfaces to administrate and participate in such an election, and showing the world what it could look like.

In the course of developing these procedures, Voatz ran a pilot of their app, giving voters and administrators alike a taste of what online voting could be like, and sometime thereafter, they came under fire for the security stance of their pilot system. A team of advanced security researchers at MIT wrote a paper decrying the Voatz pilot as an insecure approach to online elections and warning the public that such solutions cannot be trusted to uphold the operations of modern democracy. Shortly thereafter, security firm Trail of Bits published a report outlining vulnerabilities in Voatz’ application and infrastructure in greater detail.

These events seem to have led to a great deal of uncertainty and doubt of Voatz’ suitability as a provider of solutions in the elections space. If their pilot was so insecure, can the company be trusted to produce solutions for use in secure elections?

As one trained in the same kind of cybersecurity analysis and techniques as were employed by the research team at MIT, I would like to share my view on these events. Elections are enormously complex endeavors that require coordination of many people and organizations, and this succeeds today by using various different procedures and methods, but a transition to online voting will massively disrupt these procedures, and nobody is yet sure how that can possibly work. Voatz is helping to find ways that it can, even while the full security architecture of a final solution is still uncertain. To do this, Voatz is working with security standards well understood by the industry today, building voting system demonstrations based on the standards we might expect from existing major tech companies.

The MIT review raises legitimate concerns about the viability of Voatz’ approach for secure elections. In a sense, the MIT researchers are pointing out that while they themselves don’t know what the security architecture of a fitting solution for online elections would be, they can clearly see that the Voatz approach isn’t it. And while this may be true, it completely misses the value of Voatz’ contribution. Voatz is showing us how online elections can look, even before the full picture of how they can work comes into focus. It doesn’t exhibit the final security architecture, and it doesn’t need to: Voatz is building to the security standards we understand today to show us how the final solution could look tomorrow.

Meanwhile, the Trail of Bits report was commissioned by Voatz to evaluate the security of their pilot against the standards Voatz was aiming for, and the vulnerabilities disclosed by that report, while serious in nature, are not fundamental flaws, and should be relatively easy to fix.

In conclusion, we at Follow My Vote are grateful to Voatz for the work they are doing to further the conversation on how online voting solutions may look in the future, how online elections can be orchestrated, and what it will be like to participate in them. We look forward to seeing what they produce next, even as we are researching and developing the foundations and underpinnings that will eventually enable applications to be deployed meeting the full security, privacy, and end-to-end verifiability requirements necessary to support modern political elections online.

The post A Word for Voatz appeared first on Follow My Vote.

These dApps (or decentralized applications) are similar to standard apps except that they run on a decentralized network of computers, not one centralized location. They will operate in a similar fashion to normal apps in terms of the user-interface (UI), but will essentially be based on a smart contract. They are seen as the future of blockchain by many and allow people to both use and participate in the services offered by these dApps.

While there are numerous places that these dApps can be hosted, many dApps found their home on the Ethereum blockchain. It has been around for years. Ethereum is the second largest cryptocurrency according to its total market cap, and the third most expensive coin in terms of USD (i.e. $260 per Ether). It is a safe bet as it hosts thousands of different dApps. However, recently, a new contender has risen to the occasion and is giving Ethereum a run for its money. That contender is EOS. But why? What makes EOS and its blockchain attract so many projects and people away from Ethereum?

With that in mind, this article is going to take a look at a few reasons why more dApps are beginning to move over to the EOS ecosystem. However, before looking at why dApps are making the switch, let’s learn a little about EOS itself and how it came to be.

What is EOS?

EOS is a powerful infrastructure for decentralized applications. They make it simple to design dApps that are both vertically and horizontally scalable, as well as ensuring usability and flexibility. All different types of apps can be created – from ones to share music to ones to track your fitness and everything in between.

EOS is a new kid on the crypto block, as its ICO began in June 2017. In total, their ICO was able to raise over $4 billion, despite them not even having a live product, which was unheard of. According to the amount raised, this was the largest ICO in history. Several big players and notable names were investors during its ICO.

Despite being so new, EOS is already making waves in the crypto world. In addition to having the largest ICO ever, EOS is also the 6^th largest cryptocurrency on the planet according to its total market cap. So now that you know a little about EOS, let’s finally take a look at why so many dApps are moving over to the EOS blockchain.

Reasons for dApps Moving to the EOS Ecosystem

It Runs Smoothly

First of all, EOS is said to run much more smoothly than other blockchains like Ethereum and NEO. When many transactions are being processed on the Ethereum blockchain, it tends to take a decent amount of time and be a little choppy. This type of thing is not an issue with EOS.

Scalability is one of the huge selling points of EOS. It is now able to process over 3000 transactions per second and is believed to scale to million TPS. Whether your app only has a couple of users, or millions, EOS will ensure it runs smoothly and won’t experience any hiccups or crashes. The platform is also capable of handling thousands of different dApps at the same time. Certainly this scalability for large and small projects alike is one reason why more dApps are moving to EOS.

No Transaction Fees for Users

Another gripe many users and developers of dApps have with the likes of Ethereum is the fact that there is a fee for nearly every kind of transaction. While these transaction fees are usually quite small and manageable, they can definitely add up over time. On the other hand, EOS charges no transaction fees, which is obviously a huge plus for users.

This means tokens can be sent free of charge and there is no cost at all to call a smart contract. Of course, developers still have to pay some operating costs. In general, EOS is much more efficient than other options as it uses a delegated proof-of-stake (DPoS) consensus algorithm that doesn’t require traditional mining.

Increased Transaction Speeds

In addition to the platform and dApps running smoothly, and transactions being free, EOS also boasts faster transactions than most other blockchains. As mentioned before, EOS can process thousands and thousands of transactions per second, while many other blockchain systems are only capable of hundreds per second.

By having faster transactions, you ensure that users will have a better experience on your dApp as they won’t have to wait for their transactions to go through. While other blockchain systems could make strides to improve their speed, they have a lot of catching up to do.

So essentially, it is the scalability, speed and low fees that is drawing many creators, developers and publishers to EOS. It remains to be seen just how many dApps will ultimately be hosted on EOS, but plenty have already moved or have said they are planning to do so. While it may be awhile before EOS completely takes over Ethereum for the largest host of dApps, it will be exciting to see what happens as both jockey for the position.

In conclusion, hopefully this article has been able to shed some light on why more dApps are moving to the EOS ecosystem.

About The Author:

Mary Ann Callahan – Follow My Vote Blog Contributor

“As an expert on Bitcoin-related topics, I’ve found myself as a Journalist at Cex.io – cryptocurrency exchange. I’m working on articles related to blockchain security, bitcoin purchase guides or bitcoin regulations in different countries.” – Mary Ann Callahan

Are YOU interested in contributing an article to Follow My Vote’s blog?

Contact Us today to find out how!

The post More dApps are Moving to the EOS Ecosystem – Why? appeared first on Follow My Vote.

Did you know that public ledgers have been used for centuries? Blockchain is essentially a more advanced digital version.

Image Source

Stephen Kendal is an advocate of blockchain technology & the applications the tech has for global financial markets and in particular the effects on derivatives & global trade.

Kendal recently wrote an article on Steemit.com detailing a great explanation for blockchain using old fashioned public ledgers:

IT’S JUST A DATABASE

Once you have managed to fix someone’s attention on a Database being nothing more than a digital list of records it is easily then to explain that this digital list of records is no different than the old fashioned written/typed ledger that were around before computers.

By simply breaking it down into bite sized chucks most people will be able to keep up.

Now that they are thinking of a written/typed ledger explain to them that in some occasions these ledgers were made public for everyone to see.

By simply referring back to the old fashioned Public Ledger that have been around for Centuries for the ones that struggle to understand what Blockchain is this is where you have to take them.

Now that they are focused on this old fashioned Public Ledger you are getting close to seal the deal and finally explain what Blockchain is.

PUT THE TWO TOGETHER

Having now explained and focusing their mind on Databases and Public Ledgers simply tell them to put the two together.

At this point you simply say that Blockhain is nothing more than a generic name for a Digital Distributed Public Ledger and is in essence a Database that is shared identically across a network of computers.

Read the full post on Steemit.com

About the author: Will Long is the Marketing Manager of Follow My Vote.

The post Public Ledgers Are Not New – Blockchain Technology Is Just a Digital Version appeared first on Follow My Vote.

Large corporations tend to store lots of contracts and legal documents in Microsoft Office. Now with the new blockchain features, users can certify and sign documents, to verify they have not been tampered with.

The new feature in Office allows validation on both the Bitcoin blockchain and Ethereum blockchain.

See the diagram below:

These new features are possible because of an Office add-on from Stampery.

Stampery is a company leading the blockchain industry with data certification.

“Both the Bitcoin and the Ethereum blockchains are fully distributed, permissionless and transparent: anyone can access them from anywhere in the world. While the content is not stored in the blockchains, the proofs of the integrity, existence and ownership of such content can be independently verified by anyone, whether it be a sysadmin, a judge in court, a digital forensic or a lawyer. Also, these proofs will remain stored in the blockchain forever, even if Stampery disappears.”

The legality of storing information on a blockchain.

“In United States Federal Courts, blockchain-based hashing and time stamping can make for exceedingly strong evidence of the authenticity of a document. Computer file hashes are widely-accepted by technology experts and the federal courts as reliable indicators of document identity. Scaled blockchains are widely-accepted by technology experts and academics as reliable data sources. Taken together and applied to the recordation of important documents using Stampery, these technologies can make for a persuasive showing that a disputed document is identical (or not identical) to an original document.”

The Follow My Vote Team applauds Microsoft for taking advantage of blockchain technology and being innovative. We are hardcore believers in the tech and strongly advise all people to learn and study these distributed ledgers.

Learn about blockchain technology.

Source: Steemit.com/@kingscrown

About the author: Will Long is the Marketing Manager of Follow My Vote.

The post Microsoft Takes Advantage Of Blockchain Tech, Adds New Features To Office. appeared first on Follow My Vote.

Follow My Vote CTO, Nathan Hourt, is responsible for owning a critical role in the design and development of the Graphene Toolkit, which was first built for BitShares, a leading crypto-currency that has been credited with several industry innovations.

The Graphene blockchain framework also powers the Steem blockchain, PeerPlays blockchain and Golos blockchain.

@pnc on Steemit.com shared this Graphene blockchain ecosystem mapping. Follow My Vote is featured in the registry section.

It is really cool to see all the projects and apps utilizing Graphene technology in one graphic.

Definition of Blockchain

A blockchain is an audit trail for a database which is managed by a network of computers where no single computer is responsible for storing or maintaining the database, and any computer may enter or leave this network at any time without jeopardizing the integrity or availability of the database. Any computer can rebuild the database from scratch by downloading the blockchain and processing the audit trail.

Simplified Blockchain Definition

“The blockchain is actually a way to structure data, and the foundation of cryptocurrencies like Bitcoin. This coding breakthrough—which consists of concatenated blocks of transactions—allows competitors to share a digital ledger across a network of computers without need for a central authority. No single party has the power to tamper with the records: the math keeps everyone honest. Forty of the world’s top financial firms are experimenting with the tech.”

Fortune.com

Delegated Proof-of-Stake (DPOS)

The Graphene toolkit utilizes a Delegated Proof of Stake consensus mechanism. This means that the difficulty of producing a block should be proportional to the stake (percent ownership) in the network.

Instead of mining (like Bitcoin and other Proof-of-Work systems) delegates are chosen by the stakeholders of the crypto tokens. Those delegates proceed to run the network with less competition and energy than a Proof-of-Work system. DPOS systems are more efficient and allow for extremely high transaction volumes, as demonstrated by BitShares and Steem.

Other blockchains to use DPOS:  Peercoin and Nxt

More on Delegated Proof-of-Stake

Learn about Follow My Vote’s blockchain voting software.

About the author: Will Long is the Marketing Manager of Follow My Vote.

The post Understanding The Graphene Blockchain Ecosystem appeared first on Follow My Vote.

2017 will be a big year for blockchain. In this blog post, we cover the top areas of the blockchain industry and what we can expect for blockchain in 2017.

There are 7 Banks that want to go live with blockchain in 2017.

A recent CoinDesk article reveals that 7 major European banks are partnering on a new blockchain-based trade finance platform called the Digital Trade Chain (DTC).

They have a tentative plan to launch in Q3-Q4 of 2017.

Those backing the platform’s development are looking to establish a secure place to manage open account trade transactions for both domestic and international commerce. DTC utilizes a permissioned ledger, with authorized parties allowed to submit transactions on the platform.

Open account trade transactions involve products being shipped before the actual payment is due, meaning that trust among the transaction’s parties is imperative. With DTC, those plugged into the system will be able to track the progression of those transactions, from initiation to settlement.

Thus far, the banks involved – KBC, Deutsche Bank, HSBC, Natixis, Rabobank, Société Générale and UniCredit – have signed a memorandum of understanding that lays out the basic groundwork for future development. That said, the banks are looking to launch DTC sometime in 2017, with an eye to building support in markets like France, Germany and the UK.

Conferences involving blockchain in 2017

A conference that caught our eye recently is the MIT Technology Review Conference: The Business of Blockchain.

The event will be held at the MIT Media Lab on April 18, 2017. The purpose of the one-day conference is “to explore the opportunities and challenges associated with public digital ledgers, or blockchains.”

Blockchains have the power to create entirely new kinds of businesses and more people are starting to realize this everyday.

Blockchain is still relatively new. The industry is still in its infancy. We can expect a variety of new use cases to be introduced in 2017.

Bitcoin in 2017

Bitcoin is the largest and most well know blockchain project. It is currently traded all around the world and more businesses are beginning to accept Bitcoin as a means of payment.

In addition to growth and adoption, Bitcoin will focus on security and scalability. The DAO hack demonstrated the need for advanced security protocols for all blockchain projects. Scalability is also an issue.  “Today the Bitcoin network is restricted to a sustained rate of 3.3 tps (7 tps theoretical) due to the bitcoin protocol restricting block sizes to 1MB. Scalability will remain the holy grail of blockchain technology.”

Ethereum in 2017

Many people believe the public blockchain with the most attainable and impactful scalability roadmap is Ethereum.

Here are some of the Ethereum projects to look out for:

Infura is an enterprise-grade Ethereum-based blockchain infrastructure being used in IoT, and in conjunction with the public Ethereum blockchain and Inter Planetary File System (IPFS). Developers interface with Infura via Web3/RPC.

MetaMask is a bridge that allows you to visit the distributed web of tomorrow in your browser today. It allows you to run Ethereum dApps right in your browser without running a full Ethereum node.

BlockApps is an enterprise-grade Ethereum-based blockchain infrastructure solution used in banking, payments, insurance, supply chain and others. BlockApps is designed to provide a permissioned Ethereum environment which easily operates at scale, allowing applications to handle a high volume of transactions per second. Developers can build interfaces with their permissioned blockchain using a REST API.

Steemit in 2017

Steemit.com is the world’s fastest growing decentralized social media platform. Steemit connects to a robust blockchain database called Steem. This blockchain database distributes rewards in cryptocurrency to the users who bring the best content (blogs, comments, videos etc.) to the Steemit site.

On January 17th, 2017 Steemit.com was featured on Forbes.com. Author, Roger Aitken covered the 2017 comprehensive roadmap for Steemit.com.

The big news surrounds the Steemit.com migration to Amazon Web Services, the world’s largest hosting provider. Steemit has racked up over 120,000 registered users in around 6 months and they need to be able to handle more traffic as the platform grows.

Steemit Co-founder & CEO, Ned Scott is quoted several times throughout the article:

 “2017 will be our banner year and the community will see a ton of upgrades from now until the end of March. Migrating hosting to reputable third parties allows us to focus all of our time and attention on development of the site, software, and community – not on scaling or maintaining servers or hosting infrastructure.”

Follow My Vote in 2017

Follow My Vote continues to pioneer end-to-end verifiable blockchain voting software in 2017. See our Github repo for updates on our software.

In 2016, we managed to get featured on Forbes.com and successfully integrated our stake-weighted voting software with the BitShares blockchain.

It’s important to note that, when designing our stake-weighted voting system’s architecture, we designed it in such a way to ensure that our blockchain voting software was portable from one blockchain to another. (contact us if you are interested in a custom blockchain voting solution)

2016 was filled with momentous achievements for Follow My Vote. Here you can see we reached out to and networked with some of the top technology leaders and politicians. (Gary Johnson & John McAfee featured)

We anticipate that 2017 will be filled with many Follow My Vote software releases and partnerships, in an effort to bring end-to-end verifiable blockchain voting to the world.

Learn about our stake weighted blockchain voting software.

Learn about our 1 person 1 vote blockchain voting software.

About the author: Will Long is the Marketing Manager of Follow My Vote.

The post What’s In Store For Blockchain In 2017? appeared first on Follow My Vote.

Each time there is an election held anywhere in the democratic world, you will undoubtedly hear words like wrongdoing, mishandling, voter fraud and misconduct being thrown around. It has been this way since the dawn of democracy in ancient Athens almost 2500 years ago. Today, technology offers a solution so secure, even banks are adopting it’s principles.

What if there was a way that allowed for a secure voting process with greater transparency? What if this same way got rid of not just the highly insecure hackable voting machines, but also all of the inept polling officer and the long queues that every voter is forced to deal with?

This is where “Follow My Vote” comes in. Launched on July 4, 2012 by Adam Ernest, a Virginia Tech graduate, Follow My Vote functions on the principle of open and honest elections. How? By providing an online open source voting platform that promises transparency and a hassle-free electoral process with block-chain technology. Starting with a small group of  block-chain enthusiasts, Follow My Vote is now getting national attention in the mainstream. Representing at events like Politicon and Freedom Fest, Follow My Vote is making waves to grow grassroots support for their technology.

Although block-chain was invented for use with Bitcoin, the independent digital currency that is competing with the dollar, now, the ultra-safe technology for transactions is being adopted by private banks to compete. Our nation’s military wing, Homeland Security, is investing research into blockchain, to use it for cyber-security. Using “distributed ledgers” block chain is decentralized. Hacks are virtually impossible because a hack would have to occur on all distributed ledgers at the same time. Hacking a block-chain is virtually impossible with today’s most sophisticated hacking equipment.

Our current voting system is completely hackable. We all know we face sure risk remaining with the status quo? What kind of country are we to leave for future generations if we don’t even have a secure voting methods anyone can most certainly trust? When high-profile security firms endorse it, and it is estimated that around 10 million worldwide trust it for currency transactions with BitCoin, it’s only time before “we the people” claim our natural rights to ensure our votes are counted, with secure and transparent systems far more reliable than our current ones.

Back in 2012, world trends forecaster Gerald Celente predicted: “If we can bank online, we can vote online.”

Today, with blockchain technology, security is secure and everything can be audited. Blockchain is more certain than any methods of traditional vote counting by paper or conventional voting machines. Today, the viable transparency is becoming acceptable by top industries.

So while the online platform eliminates the need to be physically present to cast your ballot. Using verifiable identification for security, making sure no one can vote for anyone else, and that all voters are citizens, FMV also allows users to literally follow their vote and see where it is applied. This again proves beneficial in two ways. First, by allowing each user to ensure that their vote is not tampered with, and second, by empowering every voter with the ability to audit the election for themselves thus restoring faith in the democratic process. Vote details are put on a public ledger that allows FMV users to view and even vet an election’s results.

This has basically been the dream since the invention of the internet. But security was a major concern. Thanks to Follow My Vote’s un-crackable, asymmetrical cryptography, decentralized, verifiable public ledger system, and open-source software, all of these security concerns have not just been greatly reduced but solved to a great extent.

Bitcoin Magazine is archiving non-currency block-chain applications. Many, non-currency applications are being developed all over the world. Block-chain voting may just be one of the most game-changing applications of this revolutionary new technology.

You have a right to vote and that vote should not be compromised. With a history of voter fraud in this country, isn’t it time the people called for integrity in our voting system? A democratic republic must have a standard for vote security, now with the technology, we should settle for no less than 100% assurance in election results. It’s time the people unite and demand a solution that can secure a future, for and by the people in the U.S.A.

After a successful presentation in Sacramento, California, the company is now working to find states and communities interested in online voting. Follow My Vote Alpha has now been released and the software is ready for private enterprise to test drive the software. Once major endorsements, peer-reviewed studies and public outcry call for auditable online voting, it won’t be long before the grassroots of the United States, conservatives, liberals, and everyone in between, unite under the common banner of vote security. Follow My Vote technology will be the future of elections.

Nicolas is a former Follow My Vote Ambassador, whom has spent time educating people around the world on blockchain voting and Follow My Vote.

The post How We Can Stop All Voter Fraud appeared first on Follow My Vote.