# Importing existing resources **URL:** \ **Category:** Rack (Version 2)\ **Created:** [March 4, 2019, 11:32pm UTC](https://community.convox.com/t/importing-existing-resources/438 "2019-03-04T23:32:03Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![julian](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/julian/32/35_2.png) [@julian](https://community.convox.com/u/julian)\ **Post date:** [March 4, 2019, 11:32pm UTC](https://community.convox.com/t/importing-existing-resources/438/1 "2019-03-04T23:32:03Z")
We have a production RDS database that is not managed by convox. It would be nice if we could incorporate it into our application resources. However, creating a new database through convox and migrating it will require too much downtime. Is there a way we could either: - initialize a convox database from a snapshot of another database, or - import an existing database as a convox resource? ---
**Author:** ![alon](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/alon/32/49_2.png) [@alon](https://community.convox.com/u/alon)\ **Post date:** [March 5, 2019, 10:29am UTC](https://community.convox.com/t/importing-existing-resources/438/2 "2019-03-05T10:29:58Z")
What are the benefits of managing the database via Convox, when it isn’t ephemeral/scalable in nature? Isn’t it better to manage it outside of Convox? ---
**Author:** ![julian](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/julian/32/35_2.png) [@julian](https://community.convox.com/u/julian)\ **Post date:** [March 5, 2019, 8:34pm UTC](https://community.convox.com/t/importing-existing-resources/438/3 "2019-03-05T20:34:55Z")
I suppose so. What I appreciate about a Convox-managed database is that it is bound to the proper VPC and the `cx proxy` command can provide secure access. I know that’s stuff I can set up myself, but the value of Convox is not having to manage that myself and risk mis-configuring it. Another benefit is that as we regularly create and destroy non-production environments, and those databases are ephemeral. Is there a way to make some distinction between the two in convox.yml? ---
**Author:** ![jake](https://avatars.discourse-cdn.com/v4/letter/j/f475e1/32.png) [@jake](https://community.convox.com/u/jake)\ **Post date:** [March 6, 2019, 9:10pm UTC](https://community.convox.com/t/importing-existing-resources/438/4 "2019-03-06T21:10:20Z")
Something that I really appreciate is being able to proxy to the resources - that is very useful. ---
**Author:** ![julian](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/julian/32/35_2.png) [@julian](https://community.convox.com/u/julian)\ **Post date:** [April 8, 2019, 2:52pm UTC](https://community.convox.com/t/importing-existing-resources/438/5 "2019-04-08T14:52:39Z")
It turns out that you can initialize a database from a snapshot using the `DatabaseSnapshotIdentifier` option, at least when creating a gen 1 (`convox rack resources`) resource. I’m investigating if this works for gen 2 (`convox.yml`-defined) resources as well. ---
**Author:** ![brandontruong](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/brandontruong/32/45_2.png) [@brandontruong](https://community.convox.com/u/brandontruong)\ **Post date:** [May 14, 2019, 4:11pm UTC](https://community.convox.com/t/importing-existing-resources/438/6 "2019-05-14T16:11:13Z")
@julian did you find any solutions w.r.t. gen 2 resources? (inquiring before I investigate myself 😆 ---
**Author:** ![julian](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/julian/32/35_2.png) [@julian](https://community.convox.com/u/julian)\ **Post date:** [May 14, 2019, 4:52pm UTC](https://community.convox.com/t/importing-existing-resources/438/7 "2019-05-14T16:52:29Z")
@brandontruong Right now we are using a hack: We define a gen-2 resource in our `convox.yml` which is used for most environments. Then we have our production resource as a gen-1 resource, and during deployment to production, or CI job rewrites our `convox.yml` file to remove the gen-2 definition. It’s particularly fragile, because if someone tries to deploy to production manually, it will end up creating a new gen-2 resource and sending all traffic to it. Haven’t found a solution to this yet. [I asked about adding a option to disable gen-2 resources via env vars](https://community.convox.com/t/disable-app-resource-in-convox-yml/488), but no response. I’m still open to other suggestions on how to solve this. ---
**Author:** ![edward](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/edward/32/47_2.png) [@edward](https://community.convox.com/u/edward)\ **Post date:** [November 3, 2020, 4:45pm UTC](https://community.convox.com/t/importing-existing-resources/438/8 "2020-11-03T16:45:19Z")
Bumping this as we’re migrating from gen1 to gen2 right now and now faced with the same problem. I am surprised that it’s not possible to define a snapshot ARN for app-based postgres like you can for rack resources. Likewise is there no solution to disable resources or services? With gen-1 we used the ‘-1’ scale parameter but that now fails. ---
**Author:** ![julian](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.convox.com/julian/32/35_2.png) [@julian](https://community.convox.com/u/julian)\ **Post date:** [November 9, 2020, 4:21pm UTC](https://community.convox.com/t/importing-existing-resources/438/9 "2020-11-09T16:21:23Z")
Our convox.yml got complicated enough per-environment that we started generating it with code for our main app. It’s still not great but there’s less concern of accidentally creating an app-level resource in production. Since the initial post, I’ve learned some go and I don’t think [adding support for disabling app-level resources](https://community.convox.com/t/disable-app-resource-in-convox-yml/488) would be very difficult. It seems to me the Convox team has gen-2 in maintenance mode but will accept PRs. > I am surprised that it’s not possible to define a snapshot ARN for app-based postgres like you can for rack resources. There is [DMS](https://aws.amazon.com/dms/) which might work for you instead of initializing from a snapshot. IIRC it didn’t work for us for a very particular issue related to escaping Postgres JSONB columns but you may not run into the issue (and they may have fixed it by now anyway). > With gen-1 we used the ‘-1’ scale parameter but that now fails. IIRC with gen-2 services you can just set scale=0 instead of scale=-1. In gen-1, “-1” disabled the load balancer also but since gen-2 uses ALB instead of ELB there’s only one load balancer so there’s no more need to it off to save money. That doesn’t apply to resources though.