Changelog 🎉

Deployment Pipelines get organized 🗃️

Have you ever scrolled through a long list of deployed stacks in your Deployment Pipeline, and gotten lost or forgotten which stage you were looking at? Congratulations: you are a Stackery Power User™, and today, your life gets easier (or, at least keeping track of your deployments does).

Today we're rolling out a feature that has long been requested by our heaviest users: improved Deployment Pipeline views! Now when you scroll, the pipeline name and stage names stay on top, so you always know what pipeline and stages you're looking at. Additionally, stacks and pipelines are now sorted alphabetically, which is definitely superior to our previous system of sorting by order of similarity to our team's pets' names (who came up with that system?) 🤦.

The cutting edge of CloudFront comes to Stackery

Is your app so bleeding edge that Lambda@Edge functions no longer do it for you? Well, there's a new edge in town, and this one's coming straight from Amazon CloudFront!

As AWS announced the general availability of CloudFront Functions today, we couldn't leave Stackery users behind, so we also released our implementation: the CDN Function resource.

If you need quick header manipulation, or perhaps to validate hashed JWT tokens at a viewer request, a CDN Function will get the job done (as long as you're OK with doing it in Node.js, as that's the only language available at the moment). For CDN Functions to work their magic, you'll of course need a CDN in your stack, and then you can connect your CDN Function to the CDN's Viewer Requests and/or Viewer Responses route.

Notifications get an overhaul ✨

Oh hey, you may have noticed a new icon in your Stackery navbar. Maybe it rings a 🔔?

That's right: notifications! Rather than appearing and quickly disappearing like a disposable Lambda container, our new notifications are now like EC2: there as long as you need them (trust us, it's an improvement).

In the case of deployment errors, we've also expanded feedback and support options. Should you encounter an error that stumps you, feel free to use the chat to contact our support (the error will be sent to us) or see if you can find an answer in the blog or docs.

This Node goes to 14!

It seems like such a short time ago we were celebrating the release of Nodejs12 as a Lambda runtime. But alas, the passage of time continues, and with it, the release of subsequent even-numbered Node JS versions.

Starting today, when you add a function to your app in Stackery, the default runtime will be Nodejs14.x. For Typescript fans, we've also got an option of Node 14 (typescript). And don't worry, your Node 12 functions will continue to work as long as AWS supports them!

We'd like to notify you about our notifications...

Stackery users may have noticed that their notifications have a new look and feel lately - that's because we've been showing them some ❤️ (and development time).

This is just the first step in a series of improvements we're bringing to our notification system over the next few weeks, so stay tuned for more updates!

Bigify your Lambdas

The final week of re:Invent (for 2020, at least) is here, and with it come more improvements to Stackery. Since AWS announced an increase in Lambda memory up to 10gb, we've added the ability to super-size your Function resource in Stackery as well.

Now, when creating a Function in the Dashboard, you can enter any amount between 128 and 10,240 MB. Because AWS provisions CPUs in proportion to memory, greater memory amounts will also result in more overall compute power.

Serverless or containers? Why not both?

Today we start the flurry of re:Invent announcements with a big one: container image support for Lambda functions! Otherwise known as, the best of both the container and serverless worlds.

That means that starting today in Stackery, you can publish container images to an AWS ECR repository (or sync them over from your existing third-party repository) and tell Lambda to use the image instead of a zip archive - right in the Stackery Dashboard! Oh, and the package size limit just got a huge upgrade: from 250mb to 10gb!

Step functions step up in Stackery

We rolled out a new resource today, and it's a big update: Step Functions! Specifically, the AWS serverless State Machine resource.

Step Functions are a way to compose tasks into long-running processes, and have become the backbone of many serverless applications. Now, you can wire up tasks to functions or other resources, right in the Stackery Dashboard.

Mo' pipelines, no mo' problems!

Our CI/CD pipelines just keep getting better and better. Last month, we launched unlimited pipeline stages. If that wasn't enough, this month we've really upped the ante by launching unlimited pipelines!

That's right: unlimited!

Like additional stages, multiple pipelines are available for Team, Professional, and Enterprise plans. Developer plans get one pipeline with two stages to get started with continuous deployments.

More (pipeline) stages hit the main stage 🎭

If life's a stage, it just got a lot more interesting for Stackery deployers, because we've just expanded our Deployment Pipeline to incorporate however many stages you want to add!

That's right: want a stage for every developer on your team? No problem! Have five QA environments your stack needs to go through? Done! Or just keeping it simple with dev -> staging -> prod? Just add those environments and you're set!

Additional stages are available for Team, Professional, and Enterprise plans. Developer plans get two stages for their deployment pipeline workflow.

We're defaulting to the default branch

Users of our Deployment Pipeline know that a push to their master branch kicked off the automated deployment pipeline. Now, we've improved our pipeline to default to the default branch, whether it's named master, main, or anything else.

Over the next couple of weeks, we'll be rolling out updates throughout the app to improve functionality wherever we rely on your default branch, to make sure all our users can take advantage of Stackery's functionality, no matter your preferred branch name!

Say goodbye to Bucket Negligence Awards!

We all know security is important, but keeping your resources like Object Stores locked down in a serverless environment can be tricky when other resources need to interact with them. In fact, S3 buckets are so notoriously the target of attacks that S3 Bucket Negligence Awards are a thing!

Luckily, Stackery is here to help! Now when you add an S3 Bucket in our editor, we enable server-side encryption by default, as well as blocking public access. Here's what that looks like in the SAM template:

             Bucket:
    Type: AWS::S3::Bucket
    Properties:
      ...
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
              KMSMasterKeyID: alias/aws/s3
      PublicAccessBlockConfiguration:
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  BucketBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref Bucket
      PolicyDocument:
        Id: RequireEncryptionInTransit
        Version: '2012-10-17'
        Statement:
          - Principal: '*'
            Action: '*'
            Effect: Deny
            Resource:
              - !GetAtt Bucket.Arn
              - !Sub ${Bucket.Arn}/*
            Condition:
              Bool:
                aws:SecureTransport: 'false'

If you are using the bucket for website hosting, simply click "Enable website hosting" and the permissions will change to allow public access, but still enable encryption at rest and in transit.

Diff view now available in Deployments

Ever have that feeling when you're ready to deploy your app to production, but you've already forgotten which commits or merges are going out? Well, we've got the solution to "Friday brain": it's not drone coffee delivery (though how cool would that be?), it's diff views!

Just as you can see a diff of your template before making a commit in the Editor, now Deployments have their own diff view as well.

To check out the diff view, navigate to Deployments in Stackery. You'll need to have the Deployment Pipeline enabled, of course, and the version of your stack in the first environment must differ from the version in your second (prod) environment. You can even search commits based on SHA, label, message, or author!

Lambda Extensions now in Stackery

It's an exciting day today, as AWS just launched Extensions for AWS Lambda! That means it's easier than ever to add monitoring, observability, security, and governance tools to your functions from a variety of providers.

But what does that mean for Stackery users? Well, as is our M.O., we do all the hard parts for you! Rather than having to manually configure each Lambda to use a Lambda Extension from a monitoring partner, you just need to enter your credentials once in Stackery, and all of your functions are now orchestrated to use that extension. Easier (and more pleasant) than falling off a log!

For details on setting up specific integrations, refer to the individual docs on Epsagon, Lumigo, New Relic, and Thundra.

Deployment Pipelines go GA! 🎉

We've had this one in the pipes for a while, and thanks to our intreprid beta testers, today it's going GA: Deployment Pipelines!

Like our Verification Pipeline, the Deployment Pipeline is part of our serverless CI/CD platform that allows you to preview and verify your PRs, then automate deployment to a selected environment on merge to your main branch.

Deployment Pipelines work with GitHub, GitLab, Bitbucket, and CodeCommit repositories. To enable pipelines on your existing Stackery account, simply run stackery aws update-role --deployments enable in the CLI, and you're ready for secure, verified continuous deployments!

If you build it... you may need build variables

Users deploying locally or using CodeBuild have a new option for additional build-time configuration using the new Build Environment section in the app Settings.

Use cases include setting up NPM configuration during CodeBuild deploys, such as when using private NPM repositories that require a token, or other build-time authentication needs. If this fits your use case, give it a try!

New pricing options for serverless teams!

If you're a serverless team that's iterating quickly, you need a plan that fits your needs and allows for flexibility. That's why in addition to our Developer, Professional, and Enterprise plans, we've rolled out a Team plan for startups.

And if you're on Professional stack-based pricing right now, you can keep your current plan or switch to the new team option–whatever works best for you and your crew! Just visit the Billing tab of your in-app Settings to see the new plan and switch.

Attack of the (env) clones

Version 4.8.0 of the Stackery CLI is out today, and that version bump brings with it a new command: stackery env clone.

When you run the command, the original environment's environment parameters and secrets are cloned over to a newly-created environment. This can make onboarding new team members a breeze! Just run the command in your CLI like below, making sure to replace the relevant flag values:

            stackery env clone --source-env-name development --target-env-name development2 --aws-profile default --aws-region us-east-1 --aws-account-id 123456789012
          

Seamless integration between Stackery and Parameter Store

If you follow serverless best practices, you know that keeping your secrets and parameters out of your repo is pretty much rule #1 of serverless (actually, Rule #1 of Serverless is "Don't talk about servers in serverless", but that's a secret too).

Well, Stackery just made it a lot easier to sync your in-app environment parameters with AWS Systems Manager Parameter Store–and the other way around too! Before, the values you saved in your Environment Parameters configuration was saved to the AWS Parameter Store, but if someone on your team made changes to those parameters in the AWS Console, the value wasn't updated. Today's change allows for two-way communication between the two, so whether you update or add parameter values in Stackery or AWS, the new values will be available in both places. See the video below for a demo.

An important note: though Stackery's environment parameters are stored in JSON format, AWS uses key-value pairs in the format /{environmentName}/{parameterName}. If you would like new parameters created in the AWS Console to show up in Stackery, they need to follow the same format.

Our commitment to CodeCommit

Good news for AWS CodeCommit users who want a robust CD system: Stackery's Deployment Pipelines now support CodeCommit stacks.

Deployment pipelines are s†ill in beta, but if you've been waiting for CodeCommit support to sign up, wait no longer and get in touch to try Pipelines today!

✨New site, who dis? ✨

Oh hai, have you been to our website lately? We just took down the yellow construction tape after some major renovation, and you might not even recognize it!

Built on Gatsby, it's also now faster than ever. And if you're curious, our revamped blog is one more way we've been putting the stack in JAMstack lately–and you can spin up a similar one with our JAMstack tutorial. Sweet!

Join the JAM session with Stackery

Every been in a jam to quickly create a static website, but with the flexibility of a serverless API behind it? Well, our new jam-packed tutorial will preserve your sanity with step-by-step instructions on how to create just that!

If JavaScript, APIs, and Markdown are your jam, our JAMstack tutorial will have you jammin' that stack in your own AWS account before you can say, "pass the peanut butter"!

More stack creation options are here

Last month, we rolled out warp-speed stack creation with the click of a button. But almost immediately, many of you asked about quickly creating stacks from existing repositories.

So this month, we made it easy to create a stack any way you like: immediately, while creating a new repo, or from an existing repo. Just click the dropdown arrow to see the options, then fill out your Git details if you choose one of the latter two.

Warp-speed stack creation

Last week, we dramatically sped up the time it takes to go from signing up to deploying a serverless stack. This week, we've pointed our super-secret Speed Ray™ at the stack creation process.

Now, when you click the Add a Stack button in the Stacks Dashboard, you're automatically dropped into the editor, where you can architect your resources to your heart's content, and only save to a Git repo when you're ready to... commit to your architecture.

Sign up and deploy faster than ever 💨

We've rolled out a new, faster way to get started with Stackery and deploy a serverless stack. Users can now choose a stack embedded on a website, say for example Jeremy Daly's AWS serverless reference architectures or one of our tutorials, and click Deploy with Stackery to sign up and instantly be able to save and deploy that very stack!

Check out the video below to see the new sign-up and deploy feature in action:

While this feature is for new sign-ups only, existing users have always had the ability to visualize and quickly deploy any existing template. Need a refresher on the how? No problem!

1. Create a new blank stack
2. In the editor, switch to Template mode
3. Paste in any valid AWS SAM template, then switch to Visual mode—et voilà!

Jump the queue to the DLQ

Our SQS Job Queue resource just got an upgrade! Rather than having only a subscription output that hooks up to a Function for processing messages, you now also get the option of a DLQ, or Dead Letter Queue, output.

How do you take advantage of this queueing wizardry? Just drag an event subscription wire from your main queue's DLQ output to another queue resource, and it auto-magically becomes the DLQ for your main queue in the IaC template!

Put some layers on your lambda!

Another day, another new resource. This time we've broken out layers from a setting on your Function configuration to its own resource, for ultimate customization!

The new Layer resource allows you to configure the source path and build method of your layer, as well as specifying whether previous versions should be deleted or retained.

New: deploy over existing CloudFormation stacks

As of version 4.5, the stackery deploy command has a new flag: --cloudformation-stack-name. This allows you to pull in an existing stack that wasn't deployed with Stackery in the past and deploy it as an 'update' in CloudFormation rather than as a new deployment.

So for example, if you have a stack called 'my-awesome-app' that was deployed in the dark days before you discovered Stackery, and now you would like to manage and update it using Stackery's awesome visual tools but need the stack to stay online for your users, you would:

1. Import the 'my-awesome-app' repository as an existing project in the Dashboard or with the CLI command stackery create -n my-awesome-app --blueprint-git-url https://github.com/stackery/my-awesome-app --use-existing
2. In the root of the project, run stackery deploy --cloudformation-stack-name my-awesome-app -r master
3. Enjoy a beverage while your existing CF stack is updated!

Quickly deploy PWAs with the Website resource 💻

We've rolled out a brand-new resource today, and this one's a real game-changer! The Website resource allows you to deploy a single page or progressive web app (think React or Gatsby) with a few clicks. You can set up your source and public directories, your build command, and designate an S3 bucket to host your site, all in Stackery's Dashboard!

Oh, and if you're a beta tester for our Deployment Pipeline (which you can still sign up for by emailing support@stackery.io), that means you can set up your stack to automatically deploy the latest version of your website upon merging to the master branch of your site's Git repository. Now that's sleek!

Events rule with EventBridge!

The developers have spoken, and the developers wanted the AWS EventBridge resource–so here it is! The new Event Rule resource allows you to declare an EventBridge rule and specify an event pattern for it. You can then link that rule to a Lambda function for event processing.

To take full advantage of the Event Rule resource, we suggest familiarizing yourself with event patterns for AWS Event Rules, as they're incredibly powerful once you know how to use them.

Provision concurrency in style

If you're using Provisioned Concurrency for your mission-critical functions, we've rolled some options in the Stackery Dashboard that let you fine-tune your Lambda settings.

The options for Provisioned Concurrency include:

• Minimum number of pre-provisioned concurrent invocations
• Maximum number of pre-provisioned concurrent invocations
• Autoscale concurrency utilization (70% by default)

Repository management in the Stackery CLI

We've got a new command with the version bump to 4.1.0: stackery repository. Run it to see which Git repository your stack is linked to, and optionally change it or unlink it.

And if you hadn't heard yet, we've opened up the entire Git workflow to free Developer accounts, so if you have existing stacks that aren't linked to a Git repo, just run the following command to link your stack to an existing repo and take advantage of all of Stackery's Dashboard-based editing capabilities:

            
stackery repository -n my-stack --git-url https://github.com/myaccount/my-stack-repo
          

Aurora Serverless just got better

We've rolled out some serious improvements to the Aurora Serverless Database Cluster resource this week, including:

• Autogenerating root DB user credentials and storing them in AWS Secrets Manager (in the right environment namespace in Stackery, too) - no more accidentally storing DB passwords in your template.yaml!
• Enabling the Aurora Serverless Data API
• When you connect a compute resource to the DB, it gives you permission to get the user credentials from Secrets Manager and permission to query the DB using the Data API

All of this means that you can set up a Serverless DB in your default VPC (i.e. not in a specific VPC) and still access it from a Lambda function that also is not in a VPC, meaning cold starts are lower, and you don’t have to set up a Bastion server to tunnel through to access the DB.

Get more for less free with the new Developer plan

Stackery has always played well with Git providers, with integrations for architecting, updating and deploying your serverless stacks that are as easy as pushing commits to your Git repository. But all those sweet, sweet integrations were previously reserved for our Professional and Enterprise tier users–until today!

We're rolling out our new free Developer tier, and it includes all the goodies previously reserved for paid users: Git integration, Dashboard visual editing, app-based deployments and serverless CI/CD capabilities!

The Developer plan is meant for solo devs, and is restricted to one user and one linked AWS account. If you want to bring the whole team on board, the Professional plan includes the same features for unlimited users, and comes with a weeklong free trial to kick those virtual tires to your heart's content!

Starting today, new users will automatically be onboarded to the new Developer tier. Existing users on the legacy Developer plan can follow the link below to switch to the new plan, or be automatically switched on July 1st, 2020, when we put our legacy plan out to pasture.

Introducing: Deployments!

Ok, we're not actually introducing deployments as a whole, as that's what Stackery has been helping you with since we started. However, if you logged into the Stackery Dashboard today, you probably noticed that the main navigation menu has a new section: Deployments!

The Deployments page is where you can see⁠—you guessed it⁠—the active deployments for your entire team, as well as the new Deployment Pipeline, which is still currently in beta.

Pssst: wanna be our best friend and get your hands on brand-new functionality before the rest of the masses? Sign up to be a beta tester by emailing support@stackery.io. All the cool deployers are doing it!

Oh, and fear not, your settings have not gone away! They've just conveniently moved to the User menu at the top right.

The Stackery CLI turns 4(.0.0)! 🎂

While days of the week may no longer have any meaning, at least we can all take comfort in the steady flow of version increases. And today, our CLI hit a milestone: 4.0.0! The main new feature is a more, uh, verbose stackery describe --verbose command that now lists resources by their logical IDs.

We all know what the major version bump means: breaking changes! Hopefully these are not breaking for 99% of you, but should you have a script that depends on the placement of the ResourceId in the stackery describe --verbose command, you will need to update your script to match the new formatting.

Life on the Edge gets more interesting

AWS recently announced support for the latest Node and Python runtimes for Edge Functions, so of course we were eager to implement them in our Dashboard.

You can now free yourself from the tyranny of describing your Edge Function's runtime in YAML when instead you can select it from a drop-down menu, like the civilized developer you are!

Making your pipe(line) dreams come true

Today we pushed out a major update to Stackery, and to your CI/CD process: Verification Pipelines! Now, you can run automated vulnerability checks, unit and integration tests, as well as see a preview deployment of your stack whenever a pull/merge request is opened or updated.

To turn on this new feature, head to the Stack Settings page of one of your stacks, and enable your verification options. You'll also need to choose one of your environments as your Verification Environment for preview deployments and integration testing.

Once upon a runtime... 🏰

For many moons, DotNet was alone in the Lambda Kingdom, jealously watching as its companions, Node and Python, played with all of their many versions. Even Java had two eventually, but poor DotNet was always by itself.

Alas, the day hadth come when DotNetCore2.1 was joined by another: DotNetCore3.1, a new arrival to the Lamdba Kingdom from the principality of Redmond.

And the people did rejoice! (And the people did also use the Amazon Linux 3.0 CodeBuild image to successfully deploy their dotnetcore3.1 functions).

Imagine all the build images...

In our latest update, we've expanded your options when it comes to the build images used by CodeBuild when deploying out your stacks.

By default, newly-created stacks will be set to the current latest Amazon Linux, version 3.0, whereas existing stacks will continue to use Ubuntu Standard 2.0. These settings can be changed in each stack's Settings page.

Note that in order to choose a build image, your stack needs to be set to use the CodeBuild deployment strategy. To learn more about using build images and which one to use for your runtime, refer to the AWS docs linked to below.

HTTP API FTW

Have you heard about HTTP APIs? We won't blame you if you haven't—after all, they just went GA today. But if you're building out a new API and want an option that's lower latency and lower cost, you should give them a spin—and now you can in the Stackery Dashboard!

HTTP APIs (or REST API v2) allow you to connect authorizers directly to resources such as a Cognito User Pool Client without having to go through a Lambda function as in the previous (v1) version of the REST API.

Note that because HTTP APIs are a relatively new feature, they may not yet be supported in every region, and they lack some of the options of REST APIs such as private or edge API types or certain security features.

The original was so good, we decided to add more SQLs 🥁

If you're porting over an existing application to serverless^* and need to run a Microsoft SQL server instance, you're in luck! Stackery's visual editor now supports setting up an MS SQL server in four flavors:

• MS SQL Server Express
• MS SQL Server Web
• MS SQL Server Standard
• MS SQL Server Enterprise

To add an MS SQL Server instance, add a Database resource, select Single Database Instance as the type, then pick your flavor. Be sure to specify at least 20gb as the storage size per CloudFormation specifications.

Bye, bye, Node 8! 👋

You know how it is: you've gotten comfortable with a version of Node.js, broken it in so it fits just right, and then suddenly AWS is forcing you to upgrade to a Node with a bigger screen (OK, maybe just a higher number).

Alas, the fate that all of us will meet one day has come for Node 8.10. According to the AWS Runtime Support schedule, Node.js 8.10 is EOL, and will no longer be supported for updates on February 24, 2020. Accordingly, we've removed it as a runtime option from the Function resource.

Well, that got dark fast. Anyway, we're telling you to upgrade your Lambdas before they stop working, so get on it!

Got nested stacks? Deploy them with the Stackery CLI!

Is your repository the code version of a Russian doll? Does keeping all of your applications in one huge directory give you a feeling of immense satisfaction? If so, good news! Stackery now supports deploying nested applications.

When deploying a nested app with stackery deploy, each template.yaml configuration file is built and deployed as part of the overall deployment, no matter how many nested stacks you have^*.

One command to rule them all

The newest version of the Stackery CLI removes the need for flags when running the stackery deploy command. That's right: you can now run stackery deploy flagless and fancy free—try it out!

How easy does this make creating a serverless app? Well, you can now have a new app up and running with three simple commands:

1. stackery init to create your stack
2. stackery edit to visually architect your stack and scaffold your functions
3. stackery deploy to deploy your stack to CloudFormation

Easy as pie, if that pie came delivered to your house staight from AWS.

...and now I want pie. 🥧

Put cold starts on ice! 🧊

Happy 2020! We're starting the new year off with a much-requested feature ever since its announcement at last year's re:Invent: provisioned concurrency.

When adding a function, you can now click the Provision Concurrency checkmark and say goodbye to cold starts as AWS automatically keeps a designated number of instances of that function initialized and ready to respond within double-digit milliseconds (i.e. blazing fast). Clicking the option will add the following to your serverless template:

            
  Function:
    Type: AWS::Serverless::Function
    Properties:
      ...
      ProvisionedConcurrencyConfig:
        ProvisionedConcurrentExecutions: 25 (number specified in the panel)
          

Go ahead, try it out in your mission-critical functions—just be sure to keep an eye on your stack's bill, as provisioning any resource does tend to increase costs.

December is for squashing bugs

Ok, we admit: it's been a while since an update to the ol' Changelog. But lest you think the Stackery crew has renamed itself the Slacker-y crew, we just wanted to let you know that a lot of little improvements and bug fixes have been rolling out throughout the month—they may just not be visible. These include:

• The local editing experience in both the VS Code extension and using the stackery edit CLI command is now much more stable
• A better experience for GitLab users
• The Aurora PostgreSQL RDS knows its port now (poor guy was so lost before)
• Our CLI has had a few version bumps 👊
• And we've also rolled out some accessibility improvements for our Dashboard

So this may be a good time to let you know that should you hit a bug we may have missed, you can always reach out via the in-app chat as well as emailing support@stackery.io, and we'll get back to you as soon as we can!

Did somebody ask fur moar runtimes?

Do you need new runtimes right meow? Well, we've got them, hawt off da presez: Nodejs12.x, Python 3.8, and Java 11 are all now supported by AWS and available as runtime options for your Lambda functions.

Sadly, LOLCODE is not one of the runtimes supported by AWS Lambda (yet... 😼).

A stack in the dark 🌙

For those of you who lean towards the dark side of the force (or just your browser settings), Stackery has a treat for you: our entire app has gone dark. Fear not⁠—it's not an outage in us-west-2, it's just dark mode!

To check it out, just flip the switch on your OS to dark mode. Once you go dark... you can always flip back to light, TBH. But why would you want to?

Node runtime: now with a Typescript flavor!

Are you a Typescript fan? Does seeing your code in .ts files give you the warm and fuzzies? Then it's your lucky day, because now you can choose Typescript as a runtime option for NodeJS, and Stackery will scaffold boilerplate files in all of their strongly-typed glory!

Want to get started with Typescript and Stackery? Check out the freshly-updated Quickstart in Typescript and deploy your first serverless Typescript app with us!

History is written by the deployers

They say history repeats itself, and if you're using continuous deployment, that's even more true. Luckily, you can now easily view a history of all of your deployments, either by stack, environment, or both.

To try it out, be sure you've updated your Stackery CLI to at least 3.6.0, then run stackery history -n your-stack-name (or stackery history -e your-env-name for environment-specific history). You can even narrow down your results to a particular timeframe by using the --start-time and --end-time flags!

Admin controls added across Stackery 🔒

Great news to teams using Stackery - you can now designate admins and non-admins from the Users tab of the Settings section of the Stackery Dashboard!

For existing users, there should be no change in functionality, other than now being able to take away admin privileges from existing team members (Just be mindful if you do so - the water cooler may get suddenly awkward). New users that sign up for individual accounts will be the admins of that account by default, and then can choose whether to designate other users as admins when inviting them.

Admins have permission to delete users from the organization's account, change billing plans, and designate who and who is not an admin. When inviting a new team member, only admins can make other admins. Think of it as knighthood for devOps! ♞

A streamlined Codebuild experience

This month, we've been working on some less-visible, under-the-hood changes to Stackery that you may not have noticed, but we hope they've improved your experience with our Dashboard and CLI. One of those is our Codebuild deployment process.

The most significant change is to what we took away: namely, installing unneeded runtimes when building your Codebuild deploy. This should greatly improve the speed of the build stage, allowing you to get back to work that much faster (that is what you wanted... right?).

AWS Databases: Now with 100% more graphs!

Happy September! To start the month off right, we're rolling out a new resource available in the Stackery Dashboard: The Graph Database, i.e. an Amazon Neptune graph database resource.

Amazon Neptune is a fully-managed graph database service that allows serverless applications to interact with highly connected datasets. It's... wait for it... out of this world!

The token way to create your tokens

Using the Stackery CLI is straightforward for most users, but occasionally someone needs more than running stackery login to be able to use the CLI, for example when using two-factor authentication.

So this week we introduced a way to generate Stackery tokens in the Dashboard. Think of it as a token of our appreciation for using Stackery 🥁

Edit locally on Firefox (again)

A few of our non-Chrome users may have noticed stackery edit misbehaving in browsers other than Chrome recently. Well, that's no more as we've rolled out a fix for all the... ok, most of the browsers out there (we take no reponsibility if you're trying to run Stackery on Netscape Navigator_*).

Stackery is now on the market(place)!

On the market for some professional serverless tooling? You're in luck, as Stackery is now available on the Amazon Web Services (AWS) Marketplace! Want in-app Git versioning, preconfigured CI/CD deployment strategies, Dashboard triggered deployments and our famed Visual Editor? How about the ability to write bug-free code?

Ok, so we can't give you that last one, but we can give you the ability to upgrade to the Professional plan right from your AWS account to get all of the other features of a Stackery Pro account. Click the button below to get started!

A superior local editing experience

Oh hey, have you used stackery edit lately? You may have noticed a more unified experience in the browser...

For our Pro users, non-local mode still looks the same for stacks linked to a Git repository:

Get the new version of the Stackery CLI with stackery update to try it out!

We've also got some updates to the Stackery VS Code extension that improves a focus issue with VS Code. Update to version 1.0.6 and give it a spin!

Our CLI just keeps getting better

We've rolled out another update to the Stackery CLI this week. It includes --start and --end times for logs, prompting for AWS region as well as the ability to use existing stacks in interactive deploys, fixed error messages, and a tweak to local invoke/start-api output for node10.x.

But don't think the CLI is doing all the heavy lifting this week. You may have noticed some improvements in the Stackery Dashboard, including better template.yaml path handling, an easier way to add Blueprints for our Professional plan users, as well as improvements in the way stacks that are not linked to a Git repository are handled.

Stackery hits 3.0! 🥳

The Stackery CLI hit 3.0 today! So what's new? A whole bunch of features for local workflows, including the ability to use deploy hooks to build your compiled-language functions when locally invoking.

Other features include a custom .gitignore created with the stackery init command, a default of no Git provider for stackery create, and improvements for our Windows users.

Note: this may impact anyone running a script that depended on the stackery create default to create codecommit repos. If that's the case for you, you can manually set the provider flag like so: -p codecommit.

This one's for all the Typescript fans

Have you ever thought, "I like Javascript, but it needs more types!" Then you're probably a Typescript developer, and you'll be happy to hear that our Quickstart is now in Typescript!

Check out the tutorial to learn how to use Deployment Phase Hooks to transpile your Typescript code for local invoking and deploying.

A fully interactive deploy strategy

Version 2.12 of the Stackery CLI is out, and with it, an update to the stackery deploy --interactive-setup command.

Need to link an AWS account? Want to create a new environment to deploy your new stack into? It's all possible with one simple flag. Try it when locally deploying a new stack for the first time - we dare you!

Not on 2.12 yet? Get with the times! Enter stackery update in your terminal to be magically transported to the future of serverless deploys.

Locally invoke all the things! 🎆

So, you know how you needed to have deployed your stacks with Stackery to iterate on your Lambdas locally? No more!

Now, the all-powerful stackery local invoke command can invoke any function, deployed by any strategy, using any framework. Serverless Framework? AWS CDK? Good old CloudFormation? As long as it's up on AWS, it can be locally invoked, which means you can iterate your code locally against live cloud resources, for a much smoother (and faster) developer experience.

So, how do you take advantage of this extrordinary power? Get the AWS ARN of the Lambda you want to iterate on, then run $ stackery local invoke --function-arn {ARN} --source-dir ./src. But remember, with great power comes great responsibility...

Init your stack right in the CLI!

A new Stackery CLI is in GA, and with it, the new stackery init command. Run the command in a new directory, and it'll make a blank template.yaml and stackery-config.yaml for you to get you started on your new serverless project. You can also pass the --stack-name flag and a project directory with that name and the config files will be created!

Oh, and if you're new to Stackery, the stackery deploy command has a new --interactive-setup flag that will get your environment and AWS account configured.

What are you waiting for? Type stackery update in your terminal to get version 2.11.0 and all of its init goodness!

Go go golang... and Ruby!

If you like your function runtimes like you like your ice cream flavors (plentiful), you're in for a treat, because we've been rolling out new runtimes here at Stackery like they're going out of style.

First came Node 10.x support, then we jumped on the Python 3.7 bandwagon, and now we've added not just one, but two brand new languages: Ruby and Go! It's not quite 31 flavors of runtimes, but we're getting there.

Everyone needs a log!🌲

What rolls down stairs
Alone or in pairs,
rolls over your neighbor's dog?...

Ok, so we're not actually talking about that kind of log - we're talking about links to CodeBuild logs! In the app! That conveniently let you view your build process!

While before you could see CloudWatch logs from the View tab of your stack, now you can access your build logs as well, directly from the Deploy page.

It's better than bad, it's good!

See, we do ❤️ our Windows users

Last week we rolled out our VS Code extension to much fanfare... from everyone on MacOS and Linux. Unfortunately, much like the I'm a PC guy in those old commercials, we failed to deliver for PCs. But that's no longer the case!

Version 1.0.3 of the Stackery Serverless Tools extension now works on Windows! The serverless world is your oyster, Windows users, so get started!

Choose your own deploy adventure 🎲

You know the old joke, "Get two serverless developers together, and you'll have three different deployment strategies"?

Ok, so it's a new joke. That we just made up. Nonetheless, we think options are good, so we're giving you two new ones for deploying: Codebuild and Local (in addition to the previous default, or Legacy). The deployment strategy can be set in the new Stack Settings page, in your .stackery-config file, or with the new --strategy flag when deploying with the CLI.

Extending Stackery into VS Code!

The people have spoken, and it turns out a lot of the people are using VS Code to write their serverless functions. Well, now there's a way to integrate Stackery into your VS Code workflow, thanks to our new Stackery Serverless Tools extension!

You can now visually edit your templates right in your IDE, then deploy to Stackery from the CLI - wowza! Check it out in the video below, then install the Stackery Serverless Tools extension already!

Putting the (local) server back in serverless

Ever wanted to serve your serverless template locally for fun and profit? We can't guarantee profits, but serving your own template is quite fun with Stackery's new stackery edit command! See it in action in the video below, then read all all about it in the docs.

A nodeworthy update

Tensions were high last week when AWS added support for Node.js 10.x in Lambda functions. Luckily, the team at Stackery is nothing if not tenacious, so we set about tenderly updating our Editor to include Node 10.x runtimes in function settings.

So don't be tense - try it out in the app! You won't be disappointen.. d.. Oh, just try it!

Individual function IAM Roles for Serverless Framework stacks ⚡🎉

Stackery Visual Editor now improves the security of your serverless framework stacks by defaulting functions to have their own IAM roles with minimally scoped permissions. This is now the default behavior when editing serverless.yml's in Stackery, and since Stackery automatically scopes IAM permissions based on resource relationships you won't have to type a lot more YAML. 👏

WebSocket Provisioning: Only a matter of (real) time

Traditionally, a client’s role has been to request data from a server, and a server’s response has been to fulfill those requests. But WebSocket APIs give the server some agency to make this exchange of data bidirectional. And API Gateway now has support for this healthier relationship. You go, server.

Now, Stackery is making this modern union of client and server even more modern with a new feature within our visual editor. It makes provisioning WebSockets natively a snap.

Simplify Stackery CLI Commands with .stackery-config.yaml

The latest version of Stackery CLI offers a configuration feature that allows you to define default command-line arguments and environment variables. Now, you can put defaults for all commands into per-directory .stackery-config.yml files or STACKERY_OPTION_NAME env vars — no need to enter them again!

Your laptop in AWS (no, for real this time)

For years, the naysayers have nay-said, "But you can't run AWS on your laptop!" While that may still hold true (also, why would you want to?), what you can now do (as of CLI version 2.6.0) is run your Lambda functions locally against your actual cloud resources.

As a great philosopher once said, "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should". We think you should.

Check out the video below for a demo, and follow the button below that to set up your own local development environment!

What's better than just Stackery? Stackery + Friends!

It's time to add your friends to the Stackery party! Specifically, your Epsagon account, should you have one. You can now seemlessly integrate your Stackery and Epsagon accounts in both apps. Click the button below to find out how!

Context menus get more context

Environment parameters are an important part of setting up your Lambda functions. Now, you can see exactly how they're configured with our new context-full context menus!

A mile-high view of your stack activity (minus the nosebleed)

Up until today, you could see your overall activity on the homepage and your activity by environment - but what if you just wanted to see what was going on with a single stack? Well, we heard your requests and present the brand-new Stack Overview page!

Liven up your serverless templates with emojis! 🎉🎊🥳🦄

We all know writing YAML makes us 😫 - that's why we made Stackery, after all! But sometimes manually configuring your resources is unavoidable 😞. In those cases, why don't you make your templates ✨ with some emojis? Just click the button below to view our sample Serverless Emoji CRUD repo, add your 🥞 to Stackery, and 🚢 it^*!

New environment page, who dis?

It's been a little quiet in the ol' Changelog lately, but lest you think we're slacking, we've actually been hard at work completely revamping the Environments page of the app. For each environment, you now get Overview, Parameters and Secrets pages to view and store all of your environment-specific configurations. That’s better than a ten dollar sandwich!

CLI hits two point five!

Another day, another CLI release. This one brings the ability to display information about Cognito User Pools and Aurora DB Clusters using the stackery describe command, as well as displaying better error messages should (gasp!) a CloudFormation deploy fail.

Right size your architecture

Have you ever felt like your architecture and your browser window weren't quite the right fit? Stackery now detects your window size to make sure your architecture visualizations always look their best.

Stackery + EC2-Classic! Long live EC2-Classic!

Are one of your accounts considered EC2-Classic? Does that account need to stick around for a while longer? We get it! Whether it's Led Zeppelin, Jay-Z, or EC2-Classic - we understand what it means to honor their worth by keeping them in heavy rotation, so to speak. Stackery now links just fine to EC2-Classic accounts. We'll be on the lookout for the stampeding herd of classics coming our way.

Invite some clients to the User Pool party!

Does your Amazon Cognito User Pool feel a bit shallow? What if we told you that now you can dive in with a User Pool Client resource? We're confident this new addition will make a splash in your workflow.

Keep tabs on your usage

You may have noticed we've rolled out new pricing this week, and with it, a way to keep track of your active stacks, right in the app! All stack events are displayed for each of your active stacks, so you'll know right away if Tom is deploying to too many environments again (it's always Tom).

Aurora Serverless visual editing

Stackery has expanded the Database resource to allow you to configure your own Aurora Serverless Cluster. This addition takes the guesswork out of configuring capacity for unpredictable workloads and provides a highly-available database option that scales to zero.

Two, four, six, eight... No, just two point four!

Stackery CLI version 2.4 is out, and it includes the new stackery settings command. This piece of programming magic lets you add... wait for it... mono-repo serverless apps to Stackery!

✨ A brand-spankin' new homepage ✨

The Stackery app has a brand new homepage, and it's shiny! When you log in to your Dashboard, you'll see how many stacks, environments, and deployments you have, as well as your (and your team's) activity at a glance.

Broke your YAML? Now you'll know where

Before, if your template.yaml file had an error in it, your deploy would fail but you might not know why right away. Now you'll be notified right in the template editor in your Dashboard so you can fix the problem before moving on. Sweet!

Introducing the Anything resource

Stackery now correctly visualizes any AWS resource present in your architecture and provides an "Anything" resource within the visual editor. Why "Anything"? Because you can add any resource that's supported by CloudFormation. Just add an Anything resource, drop in a piece of CloudFormation infrastructure-as-code, and Stackery will visualize it!

From (wire) chaos to order

Remember how keeping track of resource integrations in large, complicated stacks used to be really chaotic? Well, it's chaotic no more! If you don't believe us, just see below for the before and after side-by-side.

Cognito resource now available

Did you say you wanted Cognito User Pools? Well, in our latest release you're getting Cognito User Pools, along with all of their lifecycle event goodness. Huzzah!

Hot dog! A new Deploy page!

If you logged into Stackery this morning and prepared or deployed your serverless app in the Dashboard, you may have noticed our new and improved Deploy view. And if you haven't - what are you waiting for? You can now see all of your deployments across all of your environments, and sort by prepared or deployed states as well. Shiny!

Bitbucket Cloud and Server integrations

Great news for all Bitbucket users - now you can add your Bitbucket repos to Stackery! Whether in the cloud or on-prem with Bitbucket Server, you're A-OK with us!

Configuring CORS is a hassle (no more)

CORS used to be a pain, but no more! Stackery allows you to enable CORS in your Rest API resource with just the click of a box. Easy peasy lemon squeezy!

Logical IDs: now 100% customizable

For all of you who banged their heads against the wall when trying to debug function234B48EO2 in the AWS CloudFormation logs, this one's for you. You can now rename your functions, APIs, and other resources to anything you like - as long as it's proper CloudFormation yaml, that is.

Template diff view is live!

Ever wonder what's happening under the hood of your `template.yaml` when you're adding or deleting resources in the Editor? Now you'll see exactly what was changed every time you commit. Neato!

Lambda layers come to Stackery

Just as AWS announced Lambda Layers, Stackery announced layer support (and a new PHP layer). That means you can now use any runtime for your Lambda, should you be so inclined. We truly live in the future.

Edit your YAML right in Stackery

We've got some big changes coming today! You can now edit your `template.yaml` config right in the Stackery app, without having to open a single IDE! Just open a stack, go into the Edit view, and select "Template" for your edit mode. Go on, you know you want to.

Livin' on the edge!

Edge Functions have arrived in Stackery! For all of those times when just a CDN won't do. And if you're not sure what Edge Functions are and why you might need one, click the link below to read all about them.

Keep those secrets secret

You've got secrets, I've got secrets, we've all got secrets! Luckily, the AWS Secrets Manager is a great place to store them, and also a new resource available in Stackery.

Extending Stackery capabilities to Serverless Framework

We love helping serverless teams accelerate and manage projects and environments regardless of whether they started with Stackery or not, so we’ve recently made improvements to importing projects and code for AWS SAM, Serverless Framework, and Gitlab.

Deploy GraphQL APIs with Stackery

You know that hip new query language that's all the rage? Well, you can now use Stackery to configure and provision AWS AppSync GraphQL APIs, which is a serverless pay-per-invocation service similar to API Gateway, but for GraphQL!

Trigger Lambda function on deploy

Does your deployment processes involve multiple commands that need to be run in a certain order? Stackery now provides the ability to mark any function as “Trigger on First Deploy” or “Trigger on Every Deploy”, which provides a clean mechanism to handle database migration, ship single page apps, and handle custom deploy logic across all your environments.

Reference existing cloud resources

What happens when your Function needs to subscribe to an existing DynamoDB stream or be placed in an existing VPC? Stackery now provides the ability to replace resources in a stack with a pointer to an already provisioned resource.

GitLab + Stackery = Serverless CI/CD ❤️

As of today, Stackery features full support for GitLab source code hosting and serverless CI/CD deployments. We promise this change comes from user requests, and not at all from news of a certain other Git hosting provider being acquired by a certain mega-corporation.

Stackery is now running on AWS SAM 🎉

Stackery now supports the AWS SAM (Serverless Application Model) framework natively and provides the tools for maintaining best practices, streamlining workflows, and enforcing consistency. What does that mean for our users? Better YAML (that you don't have to write)!