Backend URL Vercel
What would be the Backend URL for a Convex application deployed on Vercel?
38 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Did you see this? https://docs.convex.dev/production/hosting/vercel
Using Convex with Vercel | Convex Developer Hub
Host your frontend on Vercel and your backend on Convex.
Yes, I have. The backend URL configured in my Convex deployment ends with
.site, correct? Will this .site URL remain active indefinitely? Is Convex managing the deployment for it? I ask because I can still make requests to this URL even though my application is no longer running locally.nope, you want the
.cloud URL -- and it's going to be the one under the "production" deploymenthere's where you find it
in the dashboard
This is what I see
that's HTTP actions URL, not the deployment URL
swap the
.site for .cloud and it's the sameyup, thats what I was looking for, thanks!
Follow up, is there a way I can see the HTTP Actions in my dashboard?
I only see the queries, and routes but not the actual http actions
lastly, whenever I run
npm run dev does it also update the production deployment in convex? Or is there a way to first test the changes in dev and then run a command to push it to prod?dev only updates your dev deployment
npx convex deploy pushes to productionThanks!
@jamwt I’ve set everything up with the convex vercel guide - the deploy key ensures the front end has an up to date convex url…
But.. how do I get that to my backend?
(I’m using Tanstack and I’m calling tanstack through my serverless functions).
VITE_CONVEX_URL isn’t set when I try to spin up a new http client
@The Aleks Are you asking how to call your TanStack Start backend functions from Convex actions? Or how to call Convex Actions/Queries/Mutations from TanStack Start functions?
Is VITE_CONVEX_URL set in .env.local?
What do you mean by
VITE_CONVEX_URL isn’t set when I try to spin up a new http clientare you saying
(import.meta as any).env.VITE_CONVEX_URL doesn't work?Calling convex from tanstack start functions.
I have some workflow logic that runs on tanstack and coordinates convex (and a vector db).
It all works locally.
(I just set the env variable in .env.local)
But when I deploy it to vercel it complains about the VITE_CONVEX_URL not being set.
Which makes sense since we’re setting it just for the the front end bundle when we build and deploy
What does "workflow logic that runs on tanstack" mean, is this server functions from TanStack Start?
Yeah, it’s server functions
cool, and VITE_CONVEX_URL is set in the .env.local file? But that's no longer in the environment when the server runs?
Well yes that works
But when I deploy to vercel
There’s only what I’ve defined in environment variables inside of vercel - and what convex sets with the deploy key
so .env.local apparently doesn't work for the backend?
.env.local works for the backend.
But that isn’t present when I’m not running the app locally
Oh I thought
npx convex deploy --cmd 'the frontend build' modified .env.local
Oh yeah - that’s what I meant
Didn’t realize it was a .env.local file it created
I'm not sure it does, let's check
I’ll investigate again tomorrow, but it seems like it isn’t set on the backend when it’s deployed
You could set it manually right, but for preview deploys it'd be nice not to need to
Yup - exactly
OK testing it indeed seems not to do set it in env.local
so if your backend doesn't have a buid process where it would be bundled in like your frontend does, makes sense it wouldn't have it
but you can hardcode prod
the issue is just preview deployments
I can hardcode it for now - but the moment I start using the preview environments my backend and client will be writing to two different environments
by "hardcode" I actuallyjust mean "set the environment variable in Vercel"
Yeah, if you use preview environments this will be a problem, let's see what's the appropriate fix
Have you considered making the preview urls more predictable? Eg git name based
I wonder why this works for Next.js
I'm guessing because the build also bundles the backend
and that substitutes in the environment variable
but TanStack Start is not bundled, or doesn't bundle it in
That would make sense
This is super helpful though @ballingt - means I’m not going crazy and I can shortcut things in the morning
For now a flag for to write this to .env.local seems useful, and ideally we'll detect the right thing to based on the framework you're using in the future
I still think, if possible, some kind of logic around branch names could be worth considering.
It’ll allow preview environments to easily work in setups where there’s a separate backend that communicates with convex (more and more common these days with the AI and python craze)
There is
--preview-create whatever, but that's not enough to know the URL huh
Can you walk me through this? Seems like generally you'd want to wait for the Convex preview deployment to be ready before doing anything with it, and by that point you know the nameJust like you’re inferring the branch names and using it to name the environment I’ve in the past used it to set the environment variable in another environment.
It’s nice for the scenarios where the primary trigger for convex is vercel git based deploys.
Alternatively I could setup a full GitHub actions deploy flow and, as you’re mentioning, deploy convex first and then use the url for subsequent steps
We're not going to let you set your own happy-animal-123.convex.cloud url yet, but maybe we expose the mapping or even create some aliases
but generally we want you to deploy code, and then the result of that deploy is the URL
otherwise races, plus easy to get mismatched backends and frontends