# Theme automation **URL:** \ **Category:** Development\ **Tags:** unsupported-install\ **Created:** [May 31, 2022, 10:43am UTC](https://meta.discourse.org/t/theme-automation/228579 "2022-05-31T10:43:11Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [May 31, 2022, 6:27pm UTC](https://meta.discourse.org/t/theme-automation/228579/3 "2022-05-31T18:27:37Z")
I think that the only solution is to build an image that includes the plugins that you want, push it to a docker repo, launch it with the appropriate ENV variables, and at some point see that the database is migrated and assets precompiled and pushed to S3 on (at least) the first time the image is run. You might want to migrate once with `SKIP_POST_DEPLOYMENT_MIGRATIONS` set while the old image is running and then again after the new image has launched and the old ones have shut down with `SKIP_POST_DEPLOYMENT_MIGRATIONS` turned off or run the `db:ensure_post_migrations` rake task. > [@gabriele\_fraracci](#): > > is there a way to get an api key from discourse from a script? You can run a rake task in one of your running images, something like ``` rake api_key:create_master['description of key'] ``` > [@gabriele\_fraracci](#): > > does anyone know some kubernetees trick to workaround this kind of issue? The above might be enough to get you a bit further. I’ve run kubernetes instances for clients on GCP and AWS in the past. I was never 100% happy with how it worked (it worked perfectly from the client’s perspective, it just wasn’t very elegant from mine, but it wasn’t so inelegant that I bothered to fix it, either!). I don’t have much more to offer here, but feel free to contact me directly if you need more help. --- _[View the full topic](https://meta.discourse.org/t/theme-automation/228579)._