https://supabase.com/ logo
Join Discord
Powered by
Ok. So, the project we've been building involving...
# help
i
Ok. So, the project we've been building involving Supabase has launched and it's working fine. So, now I've been asked to figure out how to self-host it. I imagine this would have been somewhat easier last week, but, so it goes. I think the Docker self-hosting option is almost certainly the easiest choice for me. I have found the pages related to self-hosting on Docker and regarding migrating a project, but I have a few questions still. 1.) In the migration guide, it talks about "decoupl[ing] your database from the middleware", but I'm not quite sure exactly what that means in this context. If we're already using a Supabase DB as is, would that already count as being as decoupled as we'd need? 2.) Is there a guide specifically oriented towards making the switchover from a Supabase hosted Supabase instance and a self-hosted Supabase instance as seamless and invisible for users as possible?
n
Hello @itsetuhoinen! This thread has been automatically created from your message in #843999948717555735 a few seconds ago. We have already mentioned the @User so that they can see your message and help you as soon as possible! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates. Want to change the title? Use the ``/title`` command! We have solved your problem? Click the button below to archive it.
j
@itsetuhoinen Pretty sure that's just referring to having your postgresql server somewhere else other than in a docker container as part of the docker install.
n
itsetuhoinen (2022-05-20)
i
I should probably also add that I'm a sysadmin, not a DBA, so... 😄
Ah, ok. So, like, a separate postgres, perhaps on the machine that dockerd is running on, with all the other "supabase stuff" in the container?
Very, ah, technical terminology there. 😉
j
hahaha yeah 12:48am here for me so no hope of being mindful of terminology
#2 will depend on how you're setup... I would start by using direction connection and postgres tools to export the schemas and import them to your newly minted db. Then I'd go about setting up some sort of data syncing mechanism between the two so that data added to supabase is replicated to your local db. Then you'd have to setup your local docker supabase to mimic the settings of the remote db and if you've done all of that correctly... you can switch the URLs I'd assume.
i
So, then, for the actual switchover, the main thing I can think of is to set up replication (he says, alomost like he knows what he's talking about) and make sure they're as close as I can get them, and then tell the front end to start making calls to the local copy instead of the supabase copy.
Ok, so, sounds like I'm pretty close to the right track, then.
j
Yeap that's how I'd do it
Are you hosting on AWS?
i
We are not running anything on AWS. We have a front end through Vercel, the DB through Supabase, and a lot of our own systems on the back end beyond that.
j
gotcha. Only reason I ask is I figured if you were on aws you might be able to throw some support bucks at the team and if possible get an image of the aws server moved to your aws account and spun up there.
i
Ah, yeah, that would definitely be convenient.
I am already making local backups of the Supabase DB, because we wanted snapshots more frequently than the daily schedule Supabase does as part of their service. So, I have a fair close copy of things locally alreay to start from.
fairly close
Ok, cool. That sounds like a plan of action then. Thanks!
j
No worries. Hope it goes well!
PreviousNext
Powered by