cloud-seeder: A tool for interacting with AWS CloudFormation

[ cloud, library ] [ Propose Tags ]

This package provides a DSL for creating deployment configurations, as well as an interpreter that reads deployment configurations in order to provision application stacks to AWS CloudFormation using Amazonka.

[Skip to Readme]


[Last Documentation]

  • Network
    • Network.CloudSeeder
      • Network.CloudSeeder.CommandLine
      • Commands
        • Network.CloudSeeder.Commands.Provision
        • Network.CloudSeeder.Commands.Shared
        • Network.CloudSeeder.Commands.Teardown
        • Network.CloudSeeder.Commands.Wait
      • Network.CloudSeeder.DSL
      • Network.CloudSeeder.Error
      • Network.CloudSeeder.Main
      • Monads
        • Network.CloudSeeder.Monads.AWS
        • Network.CloudSeeder.Monads.CLI
        • Network.CloudSeeder.Monads.Environment
        • Network.CloudSeeder.Monads.FileSystem
      • Network.CloudSeeder.Orphans
      • Network.CloudSeeder.TH
      • Network.CloudSeeder.Template
      • Network.CloudSeeder.Types


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Versions [RSS],,
Change log
Dependencies aeson (>=, amazonka (>=1.4.5), amazonka-cloudformation (>=1.4.5), amazonka-core (>=1.4.5), amazonka-kms (>=1.4.5), amazonka-s3 (>=1.4.5), base (>= && <5), bytestring, containers, crypto-api (>=0.3), deepseq (>=, exceptions (>=0.6), lens, monad-control (>=, monad-logger (>=, mtl, optparse-applicative (>=, text, text-conversions (>=0.3.0), transformers, transformers-base, unordered-containers, uuid (>=1.2.6 && <2), yaml (>=0.8) [details]
License ISC
Copyright 2018 CJ Affiliate by Conversant
Author Alexis King <>, Michael Adlai Arnold <>
Maintainer Alexis King <>, Michael Adlai Arnold <>
Category Cloud
Home page
Bug tracker
Source repo head: git clone
Uploaded by marnold at 2018-04-19T21:30:30Z
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 2129 total (7 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs not available [build log]
All reported builds failed as of 2018-04-19 [all 2 reports]

Readme for cloud-seeder-

[back to package description]

cloud-seeder Build Status

cloud-seeder is a Haskell DSL for provisioning and controlling CloudFormation stacks. It provides an opinionated mechanism for provisioning a set of related stacks called a “deployment”. You write ordinary CloudFormation templates as YAML, and cloud-seeder helps to create a self-executing command-line interface to orchestrate their deployment.

For example consider a template that provisions an S3 bucket with a configurable name, bucket.yaml:

AWSTemplateFormatVersion: '2010-09-09'

    Type: String

    Type: AWS::S3::Bucket
      BucketName: !Ref BucketName

    Value: !Ref Bucket
    Value: !GetAtt Bucket.DomainName

Using cloud-seeder, you can create a deployment script in the same directory, config.hs:

#!/usr/bin/env stack
-- stack runhaskell
{-# LANGUAGE OverloadedStrings #-}

import Network.CloudSeeder

main = cliIO $ deployment "cloud-seeder-example" $ do
  stack "bucket" $ do
    flag "BucketName"

This file contains a declarative configuration of your deployment, but it also serves as an executable command-line tool! Since it has a shebang at the top, it can be used directly to run the deployment with a pleasant interface:

$ ./config.hs provision bucket production --BucketName my-awesome-s3-bucket

The first argument to the provision command is the stack you want to provision, and the second argument is the name of some “environment” to provision in. This environment is used to namespace the eventual stack name, so the above command will spin up a new CloudFormation stack called production-cloud-seeder-example-bucket. The environment is also available in templates themselves if they specify an Env parameter. The generated command-line interface is also robust in the face of mistakes, and it won’t do anything if a required parameter isn’t specified.

While cloud-seeder can be used for single-stack deployments, it’s far more useful when used with multiple stacks at a time, which may possibly depend on other stacks’ outputs. For example, we may now wish to serve resources out of our S3 bucket by using CloudFront. We can write a second template to do the job, cdn.yaml:

AWSTemplateFormatVersion: '2010-09-09'

    Type: String

    Type: AWS::CloudFront::Distribution
        Enabled: true
        - DomainName: !Ref BucketDomainName
          Id: origin
          S3OriginConfig: {}
        # ...

We can now add cdn to our deployment configuration:

#!/usr/bin/env stack
-- stack runhaskell
{-# LANGUAGE OverloadedStrings #-}

import Network.CloudSeeder

main = deployment "cloud-seeder-example" $ do
  stack "bucket" $ do
    flag "BucketName"

  stack_ "cdn"

We use stack_ instead of stack to omit the configuration block, since the cdn stack doesn’t need any additional configuration options. When we go to provision the stack, it will work just fine:

$ ./config.hs provision cdn production

Note that we did not have to specify the BucketDomainName parameter explicitly, because it was an output from the bucket stack, so it is automatically passed downward to the cdn stack. This allows stacks defined lower in the configuration to build on top of resources defined in previous ones.

For more information about all of the configuration options available, as well as some of the implementation details, see the documentation on Hackage.