Multiple Contexts in a Workflow

It would be useful to be able to specify multiple Context's in a workflow. As a general best security practice, any given workflow should only have access to the secrets that it absolutely needs. In order to accomplish this with Context's currently however, many projects would need their own Context, containing only the secrets relevant to that project. This defeats the point of Contexts, making them less reusable. Allowing a workflow to specify multiple Contexts maintains this principle of least privilege, without sacrificing the usability of Contexts. Exampe:


- example-job:
- Heroku
- Cloudflare


There's more discussion in this forum thread.

  • Eric Dahlseng
  • Dec 12 2018
  • Taking votes
  • Attach files
  • Chris Busby commented
    December 18, 2018 10:47

    Agreed, this is combination with some kind of access control on contexts (on a project/repo level) would make CircleCI feasible for us to use in our larger organization.

  • John McGowan commented
    January 16, 2019 16:21

    Multiple contexts would allow our CircleCI workflow/job setups to be much DRYer.   Many many upvotes for this.

  • Jesse Price commented
    January 22, 2019 17:01

    This would definitely reduce the need for contexts containing boilerplate variables. If you consider a CircleCI Context as a set in a Venn diagram, the need for referencing multiple contexts in a CircleCI workflow becomes immediately clear.  There are instances where different contexts should overlap, rather than having slightly altered copies of contexts to suit slightly different scenarios.

    In instances where the same variable exists with the same value, it should simply discard the duplicates. In instances where the same variable exists with different values, an error can be thrown on build. 

  • DONTIA MOORE commented
    March 09, 2019 14:41
    1. workflows:
      - example-job:
      - AWS
      - Heroku
      - Cloudflare
  • Simon Beirnaert commented
    April 23, 2019 12:01

    Definitely a big missing feature

  • Vinicius Correa commented
    April 30, 2019 19:08

    context seems to be an invalid property to config version 2.1, it is going to be deprecated?

  • Nathan Dintenfass commented
    April 30, 2019 21:52

    @Vinicius contexts are fully supported in 2.1 -- possible you have a syntax error, perhaps? If you think you've found a bug, please post it here:

  • Juan Marcos Bellini commented
    May 15, 2019 20:40

    I don't understand if 2.1 fully supports using ONE SINGLE CONTEXT, or MULTIPLE CONTEXTS. Because in my case, using 2.1, I'm not able to use two contexts.

  • Juan Marcos Bellini commented
    May 15, 2019 20:41

    And docs are not that complete as I would like

  • Ulysse Mizrahi commented
    May 17, 2019 15:02

    This is a huge need with monorepo microservices. Right now it leads to huge amounts of configuration, which is error prone and tedious

  • Dak Washbrook commented
    July 14, 2019 04:53

    This would be great!!

  • Matthieu Adjogah commented
    July 23, 2019 14:46


  • Pedro Tonini commented
    July 31, 2019 18:07


  • AJ Cezas commented
    August 07, 2019 01:10

    yo, why the f*** are the circle peeps so quiet on this? can we get this supported or not?? 

  • Nathan Dintenfass commented
    August 07, 2019 17:54

    We have been quiet because this hasn't yet been scheduled. We definitely have it on the list of desired context enhancements, but until we are actively designing it or have a release date there's not much more to say. That said, it's currently being looked at as part of our next set of config improvements. We will update here if and when we have news.

  • Julien Breux commented
    August 12, 2019 10:17

    For backward compatibility.

    Please, add `contexts` instead of `context`?


  • Alan Johnson commented
    August 16, 2019 18:26

    I also would support this. It could also serve as a way to differentiate job config between different workflows. In my case, I'd like to have a `nightly-build` context, which allows some long-running jobs to proceed, which are otherwise conditional. But as-is, this only works if it's the _only_ use of context.

  • Kelsey Steinbeck commented
    September 10, 2019 18:24

    any update on this?

  • Brandon Wilson commented
    September 16, 2019 22:55

    This would make contexts much more usable.

  • Jophin Joseph commented
    October 01, 2019 10:40

    This is a major miss in contexts. Having to replicate a lot of environment variables across multiple contexts now. 

  • James Pike commented
    October 15, 2019 07:04

    This is a massive oversight. I'm starting to consider if I made the right choice to go with CircleCI after having to slowly replicate 50 environment variables three times. It took me 5 hours of copy and pasting. Now my hands hurt. On gitlab CI this was a non-issue.

  • Paul White commented
    October 30, 2019 11:19


  • Malte Isberner commented
    November 06, 2019 02:31

    Agree this is a massive oversight. Either allow defining contexts that include other contexts (server-side), or add a `contexts:` key to the spec. Can't really be that hard.

  • Timothy c commented
    November 29, 2019 14:27

    There have been forum questions regarding setting environmental variables on workflows which obviously overlaps with this.

    Not trying to add anything into the work being proposed, but being able to flag a context as not containing sensitive information REALLY useful as this would then address these issues.


  • Ke Zhang commented
    December 18, 2019 18:58

    Please add this!  Now, instead of organize contexts by function, we have to organize them by topic and have many duplicates

  • Kevin Ly commented
    20 Jan 15:15


  • Milos Mircov commented
    24 Jan 16:00


  • Guest commented
    31 Jan 16:28

    Would be so helpful to have the ability to use multiple contexts. +1

  • Olumide Omotoso commented
    10 Feb 08:05

    This is a big missing feature. Already set the variables only for this not to be supported.

  • Ahmed Tarek commented
    11 Feb 01:19


    Currently being limited to one context disables quite a strong pro that we can use contexts for. Contexts have a great potential to share secure environment variables between all repos/jobs while maintaining a single source of truth and no replications.

  • Daiki Watanabe commented
    02 Mar 08:27


  • Joe Cuffney commented
    03 Mar 01:41


  • Michele Degges commented
    11 Mar 04:26


  • Sam Bryant commented
    11 Mar 16:02

    Might not be what everyone here is after but we have written a tool to help manage secrets on contexts.

    The core idea is that one context extends another (much like you would want with multiple contexts). But the tool deals with setting the required duplicate values in CircleCI. So you always just use a single context by job but that could have been made up of multiple other contexts with overrides etc based on some config files. We only open sourced the tool today so getting feedback would be awesome.

  • Yan Ferreira commented
    11 Mar 16:30


  • Guest commented
    13 Mar 19:30
    > This is a big missing feature. Already set the variables only for this not to be supported.

    This just caught me as a surprise, too, dandelion!
    I assumed it must work with multiple contexts, but right, 'context'', not 'contexts'...

    Having granular sets of variables for, say, aws, vault and share them amongst many projects - it would be great to have this!

  • Lukas Siemon commented
    27 Mar 17:55

    Very unfortunate that this still hasn't been added. We have a lot of contexts (~100) and updating them (even through a script) is a pain. Any feedback where this is on the priority list?