diff --git a/website/source/intro/vs/serf.html.markdown b/website/source/intro/vs/serf.html.markdown
new file mode 100644
index 0000000000..52aa566979
--- /dev/null
+++ b/website/source/intro/vs/serf.html.markdown
@@ -0,0 +1,45 @@
+---
+layout: "intro"
+page_title: "Consul vs. Serf"
+sidebar_current: "vs-other-serf"
+---
+
+# Consul vs. Serf
+
+[Serf](http://www.serfdom.io) is a service discovery and orchestration tool and is the only
+tool discussed so far that is built on an eventually consistent gossip model,
+with no centralized servers. It provides a number of features, including group
+membership, failure detection, event broadcasts and a query mechanism. However,
+Serf does not provide any high-level features such as service discovery, health
+checking or key/value storage.
+
+Consul is a complete system providing all of those features. In fact, the internal
+[gossip protocol](/docs/internals/gossip.html) used within Consul, is powered by
+the Serf library. Consul leverages the membership and failure detection features,
+and builds upon them.
+
+The health checking provided by Serf is very low level, and only indicates if the
+agent is alive. Consul extends this to provide a rich health checking system,
+that handles liveness, in addition to arbitrary host and service-level checks.
+Health checks are integrated with a central catalog that operators can easily
+query to gain insight into the cluster.
+
+The membership provided by Serf is at a node level, while Consul focuses
+on the service level abstraction, with a single node to multiple service model.
+This can be simulated in Serf using tags, but it is much more limited, and does
+not provide useful query interfaces. Consul also makes use of a strongly consistent
+Catalog, while Serf is only eventually consistent.
+
+In addition to the service level abstraction and improved health checking,
+Consul provides a key/value store and support for multiple datacenters.
+Serf can run across the WAN but with degraded performance. Consul makes use
+of [multiple gossip pools](/docs/internals/architecture.html), so that
+the performance of Serf over a LAN can be retained while still using it over
+a WAN for linking together multiple datacenters.
+
+Consul is also more opinionated in its usage than Serf, enabling Serf
+to be used in a wider variety of cases. Consul also uses a CP architecture,
+favoring consistency over availability. Serf is a AP system, and sacrifices consistency
+for availability. This means Consul cannot operate if the central servers cannot
+form a quorum, while Serf will continue to function under almost all circumstances.
+