diff --git a/README.ja.md b/README.ja.md
new file mode 100644
index 0000000..e8de6e1
--- /dev/null
+++ b/README.ja.md
@@ -0,0 +1,88 @@
+Dewy
+==
+
+Dewyは、主にGoで作られたアプリケーションを宣言的にデプロイするソフトウェアです。
+Dewyは、アプリケーションのSupervisor的な役割をし、Dewyがメインプロセスとなり、子プロセスとしてアプリケーションを起動させます。
+Dewyのスケジューラーは、指定するレジストリをポーリングし、セマンティックバージョニングで管理された最新のバージョンを検知すると、指定するアーティファクトストアからデプロイを行います。
+Dewyは、いわゆるプル型のデプロイを実現します。Dewyは、抽象化された、レジストリとアーティファクトストアとキャッシュストアと通知から構成されています。
+以下はDewyのデプロイプロセス図と構成を図にしたものです。
+
+デプロイプロセス図、アーキテクチャ図
+
+主な機能
+--
+
+- プル型デプロイメント
+- グレースフルリスタート
+- 選択可能なレジストリとアーティファクトストア
+- デプロイ状況の通知
+- オーディットログ
+
+使いかた
+--
+
+次のServerコマンドは、registryにgithub releasesを使い、8000番ポートでサーバ起動し、ログレベルをinfoに設定し、slackに通知する例です。
+
+```sh
+$ export GITHUB_TOKEN=****.....
+$ export SLACK_TOKEN=****.....
+$ dewy server --registry ghr://linyows/dewy-testapp -p 8000 -l info -- /opt/dewy/current/testapp
+```
+
+Github APIとSlack APIを使うので、それぞれ環境変数をセットしています。
+レジストリと通知の指定はurlを模擬した構成になっています。urlのschemeにあたる箇所はレジストリや通知の名前です。
+
+```sh
+# github releasesレジストリの場合：
+--registry ghr://<owner-name>/<repo-name>
+
+# aws s3レジストリの場合：
+--registry s3://<bucket-name>/<object-prefix>
+```
+
+コマンド
+--
+
+Dewyには、ServerとAssetsコマンドがあります。
+ServerはServer Application用でApplicationのプロセス管理を行い、Applicationのバージョンを最新に維持します。
+Assetsはhtmlやcssやjsなど、静的ファイルのバージョンを最新に維持します。
+
+インターフェース
+--
+
+Dewyにはいくつかのインターフェースがあり、それぞれ選択可能な実装を持っています。各インターフェースの説明をします。
+
+インターフェース | 説明
+---           | ---
+レジストリ      | レジストリは、アプリケーションやファイルのバージョンを管理するインターフェースです。レジストリの実装には、Github ReleasesとAWS S3とGRPCがあります。GRPCは、インターフェースを満たすサーバを自作することができ、既存APIをレジストリにすることができます。
+アーティファクト | アーティファクトは、アプリケーションやファイルそのものを管理するインターフェースです。アーティファクトの実装には、Github ReleaseとAWS S3とGoogle Cloud Storageがあります。
+キャッシュ      | キャッシュは、現在のバージョンやアーティファクトをDewyが保持するためのインターフェースです。キャッシュの実装には、ファイルシステムとメモリとhashicorp consulとredisがあります。
+通知           | 通知は、デプロイの状態を通知するインターフェースです。通知の実装は、Slackがあります。
+
+各インターフェースで必要な実装があればissueを作ってください。
+
+セマンティックバージョニング
+--
+
+Dewyは、セマンティックバージョニングに基づいてバージョンのアーティファクトの新しい古いを判別しています。
+そのため、ソフトウェアのバージョンをセマンティックバージョニングで管理しなければなりません。
+
+ステージング
+--
+
+セマンティックバージョニングには、プレリリースという考え方があります。バージョンに対してハイフンをつけてsuffixを付加したものが
+プレリリースバージョンになります。ステージング環境では、registryのオプションに `pre-release=true`を追加することで、プレリリースバージョンがデプロイされるようになります。
+
+背景
+--
+
+Goはコードを各環境に合わせたひとつのバイナリにコンパイルすることができます。
+Kubernetesのようなオーケストレーターのある分散システムでは、Goで作られたアプリケーションのデプロイに困ることはないでしょう。
+一方で、コンテナではない単一の物理ホストや仮想マシン環境において、Goのバイナリをどうやってデプロイするかの明確な答えはないように思います。
+手元からscpやrsyncするshellを書いて使うのか、をサーバ構成管理のansibleを使うのか、ruby製のcapistranoを使うのか、方法は色々あります。
+しかし、複数人のチームで誰がどこにデプロイしたといったオーディットや共有を考えると、そのようなユースケースにマッチするツールがない気がします。
+
+作者
+--
+
+[@linyows](https://github.com/linyows)