#Where and how are you hosting Payload + database?

49 messages · Page 1 of 1 (latest)

left narwhal
#

I’m a new freelance dev and I’m trying to come up with a solid, goto stack for my services which will primarily be content-driven websites and e-commerce.

My plan is to use Astro and ideally add Payload into the same project which saves me the hassle of having to host the two separately. I’m thinking this combo will probably be deployed either to Vercel or Cloudflare. The question now is the database. I’m not sure if I should self host on something like DigitalOcean or bite the bullet and pay for a managed setup like Atlas. What would be the best bang for buck configuration?

uneven oasisBOT
ionic bison
#

Have you had a look at Coolify? Im hosting several apps, dbs and whatnot through it 🙂

mortal wigeon
#

You can't host Payload on Vercel.

#

I host Payload on AWS and the database Mongo Atlas

left narwhal
dapper arrow
#

Another vote for team coolify. Just take the plunge. You’ll never look back.

kind idol
#

Hosting Payload on Render for $7/mo and using Vercel Postgres which is just Neon. It's actually a pretty good DX

ionic bison
formal harness
#

+1 on a Hetzner server with Coolify. Loads of flexibility and very cheap.

wary stream
mortal wigeon
#

Because you need a node server and think script size is too large.

rapid lodge
formal harness
#

Cloud, shared vCPU. Does the job fine, but of course depends on your project. Very happy with their price/quality balance, smaller projects run well on the <5 eur/month options they offer.

rapid lodge
#

Thanks a ton!

timber grail
mortal wigeon
dapper arrow
timber grail
#

I understand, I just didn’t want this person to think it was impossible because very soon it will be an option (or already could be if it’s early development and OP is willing to use the beta, I'm using it with Next currently for an upcoming project)

mortal wigeon
#

Yeah I'm excited. Probably just offload images to S3 though.

past finch
#

Honestly i wouldn't host anything that requires a direct access to db on Vercel because their prices are huge for that, as well cold starts

but hosting frontend is fine, i went with this setup:
Payload - DigitalOcean droplet + S3 / CDN from DigitalOcean for files, configured auto deploy with github actions / docker pull, you can as well use Coolify.
Frontend - Vercel

I'm also using monorepo structure (cms, web) and i can easily import types from cms to web (or share code between them)

I wrote a Type-Safe SDK package for payload 3.0 and my syntax for calling the REST API is literally the same as calling the Local API

import type { Config } from '@monorepo/cms';
import { PayloadApiClient } from '@payload-enchants/sdk';

export const payload = new PayloadApiClient<Config>({
  apiURL: `${process.env.NEXT_PUBLIC_CMS_URL}/api`,
  fetcher: (url, init) => fetch(url, { ...(init ?? {}), next: { tags: ['tag'] } }),
});

https://github.com/r1tsuu/payload-enchants/tree/master/packages/sdk

#

Before this, i was using the same server setup for 3.0, but had several issues:

  1. Large build times (as well RAM usage on builds), i don't know exactly what was causing this, but now It's 2 min for backend and ~1 for frontend, before - 5+ minutes.
  2. Payload forces you to use experimental React / Next, though it wasn't too much problem for me
  3. SSG is really slow when using the Local API because it requires reconnection to the DB on every generated page
  4. With Vercel i have preview deployments, which is a commonly needed thing for frontend
  5. More clear separation of the code in a monorepo, easier to follow, though It's debatable of course.
  6. JS leaks from /admin into non-admin pages and CSS leaks vice-versa

I'm still testing this, so maybe i will have a different opinion in the next month 🙂

timber grail
#

I’m going through a similar process currently with some similar experiences

timber grail
#

@past finch Curious if you've figured out a good approach for dealing with CORS for preview branches since they have dynamic urls. It isn't a big deal when the admin and frontend are served from the same project because you could use process.env.VERCEL_URL but when they're separate projects the admin would need to have the frontend url injected into the CORs config dynamically.

past finch
# timber grail <@423216344302092288> Curious if you've figured out a good approach for dealing ...

I simply don't fetch to the CMS directly from frontend, only in server components / actions
But in case if you need and you don't wanna put * into the CORS config, you can configure rewrites https://nextjs.org/docs/app/api-reference/next-config-js/rewrites#rewriting-to-an-external-url (as well you can do it in vercel.json https://vercel.com/docs/projects/project-configuration#rewrites-examples
you can configure that /api/payload becomes https://cms.project.com/api, and on frontend you would just call /api/payload (relative path)

Configuring Projects with vercel.json

Learn how to use vercel.json to configure and override the default behavior of Vercel from within your project.

next.config.js Options: rewrites | Next.js

Add rewrites to your Next.js app.

timber grail
#

I might have to delve in a bit to see but even with rewrites wouldn't the frontend still need to be aware of the dynamic url for the CMS? You couldn't hard code something like cms.project.com because thats the production url, the urls for a preview branch would be something like website-[randomstring].vercel.app and cms-[randomstring].vercel.app

#

I'm thinking its best just to only enable cors for production

past finch
timber grail
#

Its a monorepo deployed to vercel so every application has automatic preview deployments (so yes the CMS also has a preview branch which allows testing frontend updates alongside the relevant CMS updates)

past finch
#

interesting, I only deploy the CMS part on my own server, without preview deployments.
Then isn't it a bit circular problem?
With the CMS-first deploying - you don't know which domain to allow CORS, with the frontend-first - you don't know the CMS URL. thinking

#

Maybe for the CMS preview deployments you can just configure * CORS, anyway I don't think anyone can guess your random preview URL

timber grail
#

The CMS doesn't really need to know the website url, the website just needs to know the CMS url. Edit: actually you're right because of the CORS issue.

#

but when the CMS url is dynamic thats where the challenge lies, I could technically do it via something like Github actions, but just wondering if there was a simpler way to do it within Vercel itself

#

I'll delve more into it, thanks for the help!

#

I can also pose this to the Vercel team themselves since I'm sure they've seen situations where a frontend application needs to know the dynamic url of a backend

#

I reached out but if you're curious I suspect the answer will be:

  • Disable automatic preview deployments for the frontend
  • Configure a deploy hook that accepts the CMS url and deploys the frontend (https://vercel.com/docs/deployments/deploy-hooks)
  • Trigger that deploy hook on a successful deployment of the CMS
Creating & Triggering Deploy Hooks

Learn how to create and trigger deploy hooks to integrate Vercel deployments with other systems.

#

I'm gonna leave it at that as I forgot this is within a help thread and drifting off topic - thanks!

wind furnace
#

@timber grail IIRC vercel has two different preview URLs per deployment, one includes a random hash but the other is deterministic. assuming you have the current git ref available in your build step, you should be able to generate the frontend preview URL ahead of time, without waiting for the deploy to finish

#

to answer your original question -- hosting on azure. docker image deployed to azure web apps, scalable pg instance 🙂

timber grail
#

@wkd I was thinking the same thing but the deterministic url actually represents the latest deployment on a given git branch so while it would probably work in a practical sense there could technically be a mismatch of urls since Vercel maintains deployments for every commit

wind furnace
#

yeah, youre right

#

if you need parity per-commit the solution you outlined is proably the better way to go

timber grail
#

The other aspect is that Vercel does do some things like truncating the names in some cases so it feels like going down a hacky path a bit

#

Ideally it would be nice if Vercel had a way to generate the deployment url prior to the deployment so you could get the urls for both applications and inject them prior to deploying both, not sure if that’s possible though

wind furnace
#

yeah once upon a time i spent a couple hours reverse engineering their slug generating fn so i could solve a similar problem to what you're describing. definitely a bit hacy

#

i wonder if there's a way that you can assign a custom domain to all preview envs without configuring each one individually

#

so instead of <deploy-id>.vercel.app you'd get <deploy-id>.mydomain.com

that would solve your issue if it's just a cors thing

cerulean ingot
past finch