[Feature Request] Copy an environment

[jgwinner]

Select Topic Area

Product Feedback

Body

It would be really handy if we could copy a GitHub Repo 'environment' to make a new environment.

ref: https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment

For example, you'd setup your Development GHA environment, debug it, then copy to "production' and make whatever changes are needed to anything but Secrets (recreating those as necessary). It would save a lot of typing, and occasional hard to track bugs like an environment variable having a misspelling.

For security reasons, maybe copying the environmental secrets wouldn't be a good thing, but I just had to retype 3 sets of 8 environment variables ... whew.

    == John ==

[dr-uv-wildner]

we have 15 secrets.... in 4 environments... as a manual job via a suboptimal web interface (you know what I mean)
this is not only tedious but risky!

[EstebanZ]

We have around 50 secrets and variables, and it is tedious to manually enter them. What am I doing wrong? 😢

It would be interesting to have a feature that allows us to "clone" the environment without the values (part of the work would already be done, and the rest would depend on each individual). In the meantime, I suppose using a script with this API can be a good alternative to automate the creation of secrets.

https://docs.github.com/en/rest/quickstart?apiVersion=2022-11-28

[binodk-maersk]

we too have 25+ secrets and it is painful tasks to recreate them manually with different environment like dev,test,preprod and prod. Though it is one time activity, but cloning environment feature will really be a big help.

[dbsanfte]

Move your secrets management to a product like Infisical, then insert a single machine ID token as a GH secret, and you are down to one secret. Not a solution for Github sucking, but if one product sucks, use another product is my philosophy.

[tmaurst]

About to take on the task of replicating several environments and it is daunting. Being able to replicate var/secret names in an env template would be really valuable.

[uvwild]

this is an ongoing issue with secure environments. safety and security requirements versus automation.
so far I have only seen tedious manual labour to copy environments.
The challenge is to find a solution which satisfies higher security requirements.
And the person responsible is likely not to do the manual labor but has to trust a foreign system.
I am curious what the future will provide in this area of conflicting interest........

[OlegMuron]

Hi!

We have the same problem with Environments creating - 6 env with a huge amount of secrets/variables

[SujayVK18]

Same Problem With Env's creating. If we can clone them it will be very helpful.

[mvladoi]

yes, this is a necessary feature

[piotrekkr]

Copy option in UI would be great. As a workaround I try to manage my env secrets and variables using Terraform. There is a github provider available and you can create some reusable module that can be parametrized. Then you reuse this module multiple times with different environment parameters. The terraform apply will create "clones" of vars/secrets in different github environments.

[sujayrk18]

Do we have skeleton of the file where i can see
Thanks!!

[piotrekkr]

@sujayrk18 You can create a module with some required variables like environment, repository name etc. Then when using terraform, create a module directory and add a config file (e.g. github.tf) alongside with other resources. File could look like this:

resource "github_actions_variable" "cloudsql_database" {
  repository    = var.github_repository
  variable_name = "CLOUDSQL_DATABASE_${upper(var.environment)}"
  value         = google_sql_database.default.name
}

resource "github_actions_variable" "cloudsql_user" {
  repository    = var.github_repository
  variable_name = "CLOUDSQL_USER_${upper(var.environment)}"
  value         = google_sql_user.default.name
}

resource "github_actions_secret" "cloudsql_password" {
  repository      = var.github_repository
  secret_name     = "CLOUDSQL_PASSWORD_${upper(var.environment)}"
  plaintext_value = google_sql_user.default.password
}
....

Then you can reuse same module with different params like this:

module "my_app_staging" {
  source = "./module-name"

  environment                 = "staging"
  github_repository           = "my-repo-name"
}


module "my_app_prod" {
  source = "./module-name"

  environment                 = "production"
  github_repository           = "my-repo-name"
}

This will create multiple secrets and variables named:

CLOUDSQL_DATABASE_STAGING
CLOUDSQL_DATABASE_PRODUCTION
CLOUDSQL_USER_STAGING
CLOUDSQL_USER_PRODUCTION
CLOUDSQL_PASSWORD_STAGING
CLOUDSQL_PASSWORD_PRODUCTION

Here is module documentation for terraform

[sujayrk18]

Awesome thank you :)

[Roman-Ka]

Same problem, ability to rename and/or copy environments would be very useful!

[WolfEYc]

i like how other modern hosting providers will let you copy and paste a .env file's contents into a box and it generates the secrets config for you.

[gilliganc]

We are the same but mostly creating almost the same environment on all our repos we only 1-2 different fields different for the same environment on the different repos. Either having org wide environment you could inherit into a repo environment and override or being able to duplicate or export/import an environment would be great. Even if it excluded secrets or needed extra auth and restrictions to duplicate the secrets over

[otienoelvis]

I have an environment with 15 variables copying them one by one is a lot of work, this is a needed feature

[gustavovalverde]

If it helps, I created a bash script for myself to accomplish this using gh CLI, it might be useful for others. https://gist.github.com/gustavovalverde/b0e566c2da331ae51116db9f74d30583

It allows creating environments with their variables using an .env file, and copying variables from one environment to another.

[piotrekkr]

Copy works with secrets without using .env locally? I thought GH API does not allow for fetching secret values, just some metadata is allowed. Is it not the case with your script?

[gustavovalverde]

I do not manage application secrets in GitHub secrets (just a few exceptions). I haven't tested it with secrets yet, it does works with variables. For the .env file is just mapping the values and crafting the request for GitHub using eachENV=VALUE from the file.

[kozachenko-m]

2026 and we still don't have the ability to copy environments nor import from .env files. Projects are now using more than 2 env vars and 5 clicks to add one variable to one environment is outrageous.