# Layers upload on each deploy?

**URL:** <https://forum.serverless.com/t/layers-upload-on-each-deploy/6634>\
**Category:** Serverless Framework\
**Created:** [December 2, 2018, 11:48pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634 "2018-12-02T23:48:53Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![b-nroths](https://avatars.discourse-cdn.com/v4/letter/b/db5fbb/32.png) [@b-nroths](https://forum.serverless.com/u/b-nroths)\
**Post date:** [December 2, 2018, 11:48pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/1 "2018-12-02T23:48:53Z")

</div>

AWS Layers support was added in v1.34. How it seems to work right now is that every time you deploy your serverless app the layers are packaged and uploaded. However, this is not what I expected. I thought we would only want to upload/update the layer package if a file was added/removed or changed.

Is there a reason it is implemented this way? I think my deployment time would be cut down by a minute or two if we didn’t upload unchanged layers because some of my layers are large (100mb +) so they take a while to upload.

---

<div class="post-metadata">

**Author:** ![dbeja](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/dbeja/32/498_2.png) [@dbeja](https://forum.serverless.com/u/dbeja)\
**Post date:** [December 5, 2018, 7:02pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/2 "2018-12-05T19:02:49Z")

</div>

I agree. Also, every time a deploy is made, a new version of the layer is generated even if we don’t make any change to it.

---

<div class="post-metadata">

**Author:** ![dschep](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/dschep/32/783_2.png) [@dschep](https://forum.serverless.com/u/dschep)\
**Post date:** [December 5, 2018, 11:17pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/3 "2018-12-05T23:17:07Z")

</div>

You’re right about that. Looking into it now.

For the time being, one way to handle this is to have your layer & your service using the layer in different serverless projects.

In your service’s `serverless.yml`:

```auto
service: foobar
provider:
  name: aws
  language: python3.6
functions:
  hello:
    handler: handler.hello
    layers:
      - ${cf:foobar-layer-dev.FoobarLayerExport}

```

Then in a separate project managing your layer:

```auto
service: foobar-layer
provider:
  name: aws
layers:
  foobar:
    path: layer
resources:
  Outputs:
    FoobarLayerExport:
        Value:
          Ref: FoobarLambdaLayer
        Export:
          Name: FoobarLambdaLayer

```

---

<div class="post-metadata">

**Author:** ![dschep](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/dschep/32/783_2.png) [@dschep](https://forum.serverless.com/u/dschep)\
**Post date:** [December 6, 2018, 1:13am UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/4 "2018-12-06T01:13:10Z")

</div>

Update: I’ve tried tweaking the cloudformation template in subsequent uploads so that the layer definition is identical. But it still creates a new layer version. As such, the work around above is your best solution it seems.

---

<div class="post-metadata">

**Author:** ![ChristopheBougere](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/christophebougere/32/989_2.png) [@ChristopheBougere](https://forum.serverless.com/u/ChristopheBougere)\
**Post date:** [December 16, 2018, 7:49pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/5 "2018-12-16T19:49:09Z")

</div>

+1, having layers deployed only when they change would be really nice. The ffmpeg example in the [blog post](https://serverless.com/blog/publish-aws-lambda-layers-serverless-framework/) is about 50MB, which is quite long to upload and layers could definitely be the solution to upload it only once.

---

<div class="post-metadata">

**Author:** ![bkcheck](https://avatars.discourse-cdn.com/v4/letter/b/ed655f/32.png) [@bkcheck](https://forum.serverless.com/u/bkcheck)\
**Post date:** [December 25, 2018, 1:12am UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/6 "2018-12-25T01:12:40Z")

</div>

+1, hope to keep this conversation alive. Redeploying layers every time seems to eliminate a huge advantage of using layers to begin with.

---

<div class="post-metadata">

**Author:** ![diegol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/diegol/32/2036_2.png) [@diegol](https://forum.serverless.com/u/diegol)\
**Post date:** [April 1, 2019, 3:33pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/8 "2019-04-01T15:33:11Z")

</div>

I’ve done this but I redeploy my layer (creating a new version) and my service still points to the previous version of the layer, how can I solve this? without having to redeploy my service?

---

<div class="post-metadata">

**Author:** ![alirizwan](https://avatars.discourse-cdn.com/v4/letter/a/919ad9/32.png) [@alirizwan](https://forum.serverless.com/u/alirizwan)\
**Post date:** [April 1, 2019, 9:58pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/9 "2019-04-01T21:58:00Z")

</div>

+1 this is causing a huge issue blocking CI deployments. Is this resolved yet?

---

<div class="post-metadata">

**Author:** ![agutoli](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/agutoli/32/3189_2.png) [@agutoli](https://forum.serverless.com/u/agutoli)\
**Post date:** [April 1, 2019, 10:11pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/10 "2019-04-01T22:11:20Z")

</div>

It has a plugin which solves this problem.

> **[GitHub - agutoli/serverless-layers: Serverless.js plugin that implements AWS...](https://github.com/agutoli/serverless-layers)**
>
> Serverless.js plugin that implements AWS Lambda Layers which reduces drastically lambda size, warm-up and deployment time. - GitHub - agutoli/serverless-layers: Serverless.js plugin that implements...

---

<div class="post-metadata">

**Author:** ![ffxsam](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/ffxsam/32/1655_2.png) [@ffxsam](https://forum.serverless.com/u/ffxsam)\
**Post date:** [October 15, 2019, 10:18pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/11 "2019-10-15T22:18:05Z")

</div>

I noticed this too. I think (IMO) it makes more sense to just not even use Serverless at all when creating layers. I’ll probably just manually create a layer to hold my audio binaries (ffmpeg, etc), and then use the ARN in my Serverless stacks to use those binaries. That way, if I recompile ffmpeg, I can create a new version, write in the description about what version of ffmpeg it is (or whatever), and then just update the Serverless config to point to the new version.

---

<div class="post-metadata">

**Author:** ![unfor19](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/unfor19/32/3823_2.png) [@unfor19](https://forum.serverless.com/u/unfor19)\
**Post date:** [December 12, 2019, 11:13am UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/12 "2019-12-12T11:13:10Z")

</div>

I was able to avoid the `Excluding development dependencies` by zipping the layers manually and referencing them with package\>artifact\>layer.zip , this helped me to reduce deployment time by 30 sec

Project structure:

```auto
.
├── babel.config.js
├── env
├── jest.config.js
├── layers # <---
├── LICENSE
├── node_modules
├── package.json
├── README.md
├── scripts
├── serverless.yml
├── services
├── tests
└── yarn.lock

```

My layers folder:

```auto
.
├── axios
│ ├── axios.zip
│ └── nodejs
│ ├── node_modules
│ ├── package.json
│ └── yarn.lock
└── nodemailer
    ├── nodejs
    │ ├── node_modules
    │ ├── package.json
    │ └── yarn.lock
    └── nodemailer.zip

```

serverless.yml layers part:

```auto
layers:
  nodeMailer:
    package:
      artifact: layers/nodemailer/nodemailer.zip
  axios:
    package:
      artifact: layers/axios/axios.zip

```

The plugin that was mentioned earlier `agutoli/serverless-layers` didn’t work for me, I get a weird error of “could not push of undefined”

My current solution does not resolve the fact that the layers are being created+deleted each deployment.

I think I figured out why this is happening, after reading this - [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-layerversion-content.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-layerversion-content.html)  
The Lambda Layer Version is referencing an S3 object, this means that each time we deploy we upload a new S3 object, so each time we create a new lambda layer version.

I assume that this can be solved by creating the lambda layers manually and decouple them from the serverless.yml file :\

---

<div class="post-metadata">

**Author:** ![DarkSavant](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/darksavant/32/3181_2.png) [@DarkSavant](https://forum.serverless.com/u/DarkSavant)\
**Post date:** [December 12, 2019, 4:20pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/13 "2019-12-12T16:20:08Z")

</div>

I agree that the solution is to have your layers in another project. One huge reason to use layers is to share code, like writing your DB connection pooling once, deploy it as a layer, and have all your other projects use the layer to get connections. It’s great for auth layers too so you don’t have to copy paste your auth code everywhere.

Keeping them in the same project is nice while you learn them, but to share them you’ll find you’ll eventually want to move them so you’re not always trying to figure out which app project the DB layer is in then having to redeploy that project to get DB changes out.

---

<div class="post-metadata">

**Author:** ![unfor19](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/unfor19/32/3823_2.png) [@unfor19](https://forum.serverless.com/u/unfor19)\
**Post date:** [December 12, 2019, 10:44pm UTC](https://forum.serverless.com/t/layers-upload-on-each-deploy/6634/14 "2019-12-12T22:44:22Z")

</div>

agreed, lesson learned