diff --git a/resources/haproxy_config/README.md b/resources/haproxy_config/README.md
new file mode 100644
index 00000000..c0ee178a
--- /dev/null
+++ b/resources/haproxy_config/README.md
@@ -0,0 +1,11 @@
+# `haproxy_config` resource
+
+This resource represents configuration for the `haproxy_service` resource.
+Each service represented by Haproxy is connected to this resource via
+`haproxy_service_config` resource. This is because in Haproxy there is no
+support for something like `/etc/haproxy/conf.d` directory where you put
+each config in a separate file, but instead you must collect all configuration
+in one file.
+
+So this resource renders this file from data provided by collecting individual
+`haproxy_service_config` data.
diff --git a/resources/haproxy_service/README.md b/resources/haproxy_service/README.md
new file mode 100644
index 00000000..348cd1e4
--- /dev/null
+++ b/resources/haproxy_service/README.md
@@ -0,0 +1,8 @@
+# `haproxy_service` resource
+
+This resource sets up a Docker container with Haproxy code. It requires
+config to be provided by the `haproxy_config` resource (mounted under
+`/etc/haproxy`).
+
+About container philosophy, see the `README.md` file in `keystone_service`
+resource.
diff --git a/resources/haproxy_service_config/README.md b/resources/haproxy_service_config/README.md
new file mode 100644
index 00000000..fdbf60d4
--- /dev/null
+++ b/resources/haproxy_service_config/README.md
@@ -0,0 +1,5 @@
+# `haproxy_service_config` resource
+
+This resource represents config for a single service handled by Haproxy.
+It connects into `haproxy_config`. It collects all services which are to
+be load-balanced by Haproxy.
diff --git a/resources/keystone_service/README.md b/resources/keystone_service/README.md
new file mode 100644
index 00000000..aac0b259
--- /dev/null
+++ b/resources/keystone_service/README.md
@@ -0,0 +1,11 @@
+# `keystone_service` resource
+
+This resource sets up a Docker container with Keystone code. It requires
+config to be provided by the `keystone_config` resource (mounted under
+`/etc/keystone`).
+
+Basically, the philosophy behind containers in Solar is to have stateless
+containers with service code and mount stateful resources with config,
+volumes, etc. to that container. Upgrade of code then would be just about
+replacing the stateless container with new one and remounting state to that
+new container.