Deploy to Vercel

[00:00:00]
>> Brian Holt: Let's try and redeploy now. Redeploy and see how we do. View deployment. So you can see, but yeah, let's talk, like, while this is building, let's talk about normally how I would do builds and how I do it a little bit different with Vercel. Normally, I like to have my CI/CD, so my continuous integration on GitHub Actions, build the product or project after it successfully runs all the tests.

[00:00:35]
That way the supply chain is like really clear of like, this commit ran these tests with this lint, it passed all of these things, and in the same line, I can see this accomplished this, and this is the build artifact out of it. I like seeing that all of that in one space where I can guarantee this built-in and past tests, and here is the artifact that came from it. I don't do that with Vercel because Vercel is like, has a bunch of stupid tricks around building Next, and it also has a bunch of like functionality around building Next.

[00:01:07]
So I run my tests still on GitHub Actions. Vercel doesn't do that for you, but I do let Vercel build everything because then you get like preview environments and a bunch of other stuff for free. Oh, we forgot Stack Auth, can't forget Stack Auth. OK. So, let's go to our settings one more time. We have to go to our friends on Neon and we got to get user notes configuration. Need API keys.

[00:01:48]
Well, we could just grab them from local as well, because it's going to be the same ones. So these two, nope, these three. The nice thing is if you do this through the Vercel marketplace, the other way where like Vercel bills you instead of Neon, the Neon Auth does stuff, actually does get set up for you, which is nice. OK, so we have that, we're going to, Vercel. Environment variables, this is, we're going to use this for everything.

[00:02:23]
So all environments. It's going to yell at you because, which is actually appropriate. When you put next underscore public underscore, it means that these can be used publicly. Now, next public Stack publishable key, right? It's meant to be published, right? These are like client side keys, whereas like you don't want that on here, but it is warning you of like, hey, this looks like a key.

[00:02:49]
Are you sure you want to send us for production? And the answer is yes, we do. OK, there we go, redeploy. Do it this time. Otherwise I quit. View deployment. So, you can get beefier build servers, these get built for free. Our project feels like it builds pretty quickly, so I'm not super worried about it. Yeah, this should build and this should go out and we should now end up with a production deployment of our app, which will be cool.

[00:03:21]
So for one of you that was going through setting this up with Vercel for the first time, did it have you install a GitHub app? It's been so long since I've done this that I don't remember how it did it. So that you signed up for a Vercel account today, you connected it to your repo, and it didn't ask you to install any like GitHub integrations. OK. Well, we'll see if the next part works or not.

[00:03:46]
If it doesn't, stop me and then we'll go figure out why it doesn't work. Oh my God, Vercel, you're killing me. Two cron jobs? Alright, let's go delete the other one. Um, this is so annoying. I'm so upset. Do I just upgrade to premium Vercel? So what it's getting mad about is it allows you to have one cron job per project, and I have one here and this one. Full Stack Next Wiki. Cron jobs, can I just disable you?

[00:04:38]
Is that enough? Failing my build is like, it's like the worst way to tell me that Vercel, I am. I'm pleased by your little ghost, but I'm displeased by this. Like, please tell me at the beginning of my, like I'm not halfway through my build and you're like, you have two cron jobs, ha ha ha. I do like this product, to be super fair, like there's so many nice things about this that like when I run into paper cuts like this, I'm so disappointed.

[00:05:28]
OK, can you just rebuild, redeploy? This is the one that did, yeah, OK. See what they recommend here. Yeah, we can build multiple environments simultaneously, so you can like, say like, alright, here's what my preview deployment, here's what my staging deployment, and here's what my production deployment, we're not going to do that today, but you definitely could. You could switch to their premium deploy product, which builds faster because it just has bigger machines for it.

[00:05:57]
I don't really think it would, it would speed up our deployment that quickly, like we don't really have that intensive project, but if you had a huge project, it actually makes a huge difference. Prevent front and back. I wonder how they do that. I've, I don't know. Skew protection. Interesting. But it's, it's, of course, comes with an upgrade. So deployments here, let's see how we're doing.

[00:06:32]
Is it getting yelled at for having too many crons again? Probably. Deployment checks, are we down here yet? No, we're not going to put any deployment checks on here, because essentially what it's going to watch GitHub automatically for us and if our GitHub tests don't pass, it won't create a new deployment for us, which is cool. How would we configure a GitHub action for this? I will show you.

[00:07:01]
So it's the next thing that we're going to do was after the next thing we're going to do. It used to be like you had to go and like install a GitHub app. The GitHub app had to like call Vercel to say, OK, I finished, here are the results of my GitHub Actions. If you have a public repo, which I imagine most of you probably do right now, it can just see that now and you don't have to set up anything, it'll just call its own API and get that information.

[00:07:27]
Also, if you configure to deploy from a private repo, I think it should be able to do that as well, just via like webhooks. But if you do have it like running on Azure DevOps or somewhere else it's not GitHub Actions, there's an API for you to call to say my build is done, here are the results of my build, I passed, I failed, all those kind of things. So you are not necessarily tied just to GitHub Actions, it's just like the one that fits really well with it.

[00:08:17]
OK, looks like we built OK, that's cool. Oh, I'm, we're ready. So please click visit. It worked. We are out there. So this is our production deployment of app. Can we sign up and sign in? Oh, so, yes, this is actually very important for us to talk about. Why is this not working? Let me just blow that up for you. Redirect URL not whitelisted. It's because if you look at the URL here, not this one.

[00:08:49]
Look at this. Lovely URL. This is not whitelisted on Neon Auth. This is, it's a security feature and you actually cannot hack around it. The way that you would hack around it if you needed to, is that you would have some sort of like post post-deployment hook, called the Neon Auth API to insert a new whitelisted URL that includes this, and then whenever this deployment went away, you would delete that, right?

[00:09:15]
So just to kind of manually show you what I'm talking about, if I go over here to, we put this in here earlier, if I click add domain here and I put the preview deployment in here, this is what the API would do for you, right? And now if I come back over here, refresh, sign up with GitHub. Authorize Stack Auth. This now should work. Yeah, and now I'm able to log into this one, right?

[00:09:39]
So it's a security feature to make sure that you don't get like hijacked, essentially. Makes sense? OK. We're not going to show, like set up that like post-deployment hook or all that kind of stuff. It would be such a pain to do today. And actually, I'm going to argue like you could probably just say like, if you want to like do these preview deployments, and you need to do things that are logged in, it's fine to just tell the devs, go add it to the whitelist, go take it off afterwards.

[00:10:13]
It's not that big of a deal. You shouldn't be like, you're probably not doing it that often. So yeah, I would have them say like just do what I did and then come back afterwards and click remove after you're done. Yeah, OK, so we have, we've deployed to production. This is our now production app. Let's go back here, so we're now visiting this URL blah blah blah, go back. So this is now built and I think this will now be like our production deployment.

[00:11:02]
So overview. Yeah, you can actually go here by the real URL now. This is, you can put your custom domain here, but this is like our official Vercel it URL now as well. So this should also work still, because we put this in earlier, right, into the whitelist, and there you go. I hear no cheers. I hear no one be like, woo, we did it. OK, well, I either broke you or I put you to sleep.

[00:11:42]
Could be both. Could be both. OK. Good question, the API that you created in order to do the thing with the AI, the cron job on production, would it be accessible if somebody knows the? Let's do it, OK. API slash summary, what do you think it's going to do? Because it is, so it's going to try to execute the cron, but it's going to say unauthorized, right? Because we don't have that cron secret.

[00:12:17]
Right? So going back to our code. Like, it's janky, but it is secure. Unless someone gets access to your environment, which you have so many problems, this would be the least of your problems that they actually did. The part where you're getting protected is here in app, actions, no, sorry, this one route. The only, right now, the only thing that has access to this cron secret is the actual deployment of our app.

[00:12:44]
As long as the deployment of our app is not leaking this cron secret and displaying it somewhere, it never leaves the like inner wall of Vercel. So this unauthorized is coming from right here. They would have to know what this cron secret is. Does that make sense? Cool. It's a good question. This still bothers people that like you technically can still hit that API. Good reason, right?

[00:00:00]
I'm not, I'm not going to say this is a great API but it's secure enough for something of this nature.