Full-stack microservices development & deployment tool for Google Kubernetes Engine and Amazon Elastic Container Service
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
client Tweaks to where the feedback indicators are printed Dec 15, 2017
docs Renaming start up scripts; Updating docs Apr 4, 2018
examples Added deployment yaml to examples/greeting Apr 5, 2018
lib Added link to installation instructions in install.sh Dec 14, 2017
tests Started adding functionaltests Nov 20, 2017
.gitignore Added Sphinx docs Aug 30, 2017
.nojekyll Adding .nojekyll files Aug 30, 2017
LICENSE Initial commit Aug 16, 2017
README.rst README updated Aug 1, 2018
__init__.py Support for AWS services Aug 16, 2017
install-docker-ubuntu.sh Added docker installation script for Ubuntu Dec 14, 2017
install.sh Added installation script for MacOS - Darwin Aug 22, 2017
requirements.txt Update to installation and startup scripts Dec 11, 2017
restart-caastle.sh Renaming start up scripts; Updating docs Apr 4, 2018
run_tests.sh Updating run_tests.sh Nov 21, 2017
start-caastle.sh Renaming start up scripts; Updating docs Apr 4, 2018
stop-caastle.sh Renaming start up scripts; Updating docs Apr 4, 2018
tox.ini Final round of initial pep8 fixes Oct 11, 2017



Platform of containerized applications/microservices includes application/web servers, container orchestration engine clusters, and application’s external resource dependencies such as managed database servers. Platform-as-Code paradigm offers ability to define all such platform elements of a containerized cloud application using declarative configuration files. These platform definitions can be version controlled and follow software development lifecycle.


Blog article about Platform-as-Code paradigm:


CaaStle is a full-stack microservices development and deployment tool that is implemented using Platform-as-Code principles. Currently CaaStle supports Google Cloud and Amazon AWS.

Key elements of CaaStle

  • Application-centric abstractions:

    Environment is the top level abstraction. It defines container orchestration engine cluster and managed cloud services for the application. Application is composed of one or more application container/s and is deployed in the environment. You get a shell customized for the environment with ability to directly use cloud-native CLIs against the platform elements created in that environment.

  • Declarative platform definition:

    environment yaml file is used to define managed cloud resources within an environment; application yaml is used to define application container (for single container applications); pod/deployment yaml or ecs's task yaml is supported for multi-container applications. No need for platform inputs using command line parameters.

  • Platform element association:

    Integrated creation and binding of cloud resources with application containers provides view of the entire application run-time environment with appropriate platform elements associations.

  • Environment change history:

    History of operations that change the state of an environment is maintained for traceability and repeatability.

  • Non-hosted implementation:

    CaaStle is a non-hosted implementation. There is no centralized server like PaaS implementations. CaaStle can be installed anywhere alongside Docker. This architecture enables effective local development with Docker environments setup on the individual workstations or laptops. The non-hosted nature also simplifies integration of CaaStle with any DevOps workflow.

Use CaaStle to develop and deploy full-stack microservices on Google GKE and Amazon ECS:

  • Common language between developers and Ops to share the platform definition of a containerized cloud application.
  • Full-stack application view for better control.
  • Ultimate dev/prod parity between local Docker environment and production cloud environment.
  • Non-hosted implementation for simplicity and usability.

Read this for more details about CaaStle

CaaStle FAQ

CaaStle Roadmap

Try CaaStle

Developed and Tested on:

  • Ubuntu 14.04, 16.04
  • Mac OS (El Capitan 10.11.4)


  • Docker 1.6 and above
  • Python 2.7

CaaStle requires Docker to be installed. If you do not have Docker, you can install it following steps from:


On Mac OS, make sure the command shell from which you are installing CaaStle is able to run docker commands without sudo. You can achieve this by executing following command in the shell once Docker VM is up and running:

eval "$(docker-machine env default)"

Once you have installed Docker follow these steps:

  1. Clone this repository

  2. Install CaaStle

    $ ./install.sh

  3. Do cloud setup

    $ cld setup aws

    $ cld setup gcloud

  4. Start CaaStle server

    $ ./start-caastle.sh

  5. Choose a sample application from examples folder and follow the steps in the included README

Sample commands

$ cld --help

usage: cld [--version] [-v | -q] [--log-file LOG_FILE] [-h] [--debug]

CloudARK command-line tool to create and manage cloud environments for containerized applications.


env create

env list

env show

env exec

env shell

env delete

container create

container list

container show

container delete

app deploy

app list

app show

app logs

app delete

setup aws

setup gcloud

Demo Videos:

  1. CaaStle setup: https://youtu.be/88kClIy8qp4
  2. Wordpress deployment on GKE: https://youtu.be/c7pO7TO0KzU
  3. Wordpress deployment on ECS: https://youtu.be/psgFyCa2PQA

Wordpress deployment on ECS

  1. Environment definition

  2. Create environment

    $ cld env create wpenv environment-rds-ecs.yaml

    ./docs/screenshots/wordpress/env-create.png ./docs/screenshots/wordpress/env-show-available.png
  3. Create application container

    $ cld container create wordpresscont ecr

    ./docs/screenshots/wordpress/container-create.png ./docs/screenshots/wordpress/container-ready.png
  4. Deploy application

    $ cld app deploy wordpressapp wpenv app-ecs.yaml

    ./docs/screenshots/wordpress/app-yaml.png ./docs/screenshots/wordpress/app-create.png
  5. Check application status

    $ cld app show wordpressapp

    ./docs/screenshots/wordpress/app-deployment-done.png ./docs/screenshots/wordpress/app-logs.png
  6. Wordpress deployment complete

    ./docs/screenshots/wordpress/wordpress-installed.png ./docs/screenshots/wordpress/wordpress-blog-page-with-elb.png
  7. AWS console

    ./docs/screenshots/wordpress/wordpress-rds-instance.png ./docs/screenshots/wordpress/wordpress-task-definition.png ./docs/screenshots/wordpress/wordpress-container.png


  1. How is Platform-as-Code different from Platform-as-a-Service (PaaS)?

Platform-as-Code is a non-hosted implementation of platform functionality. There is no private / public hosted central server like PaaSes. This approach helps improve dev/prod parity and ability to recreate application environments anywhere.

  1. How is Platform-as-Code different from Infrastructure-as-Code (IaC) ?

Infrastructure-as-Code implementation treats every platform element as infrastructure resource. In contrast, Platform-as-Code offers application-centric abstractions that simplify modeling a deployment as per the application architecture. PaC focuses on provisioning Platform elements such as databases and their binding with the application.

  1. Deploying on Google GKE
  1. Deploying on Amazon ECS


Devdatta Kulkarni: devdatta at cloudark dot io