Now that we have our project set up ready and we've prepared the environment for agentic coding, let's go ahead and add authentication. Building this yourself means creating login screens, registration screens, consent flows, client-side logic, token validation, and user management. Realistically, months of work before you even get to your actual product. Clerc reduces all of that to a few lines of code. Using the link on the screen, you'll land on Clerc's website.
Once you're there, you can click the Start Building button, which will take you to the documentation, where you can grab the agentic prompt to paste straight into Cloud Code. On their documentation page, you can find the prompt needed to install Clerk in your project. You can of course also find the manual setup. If you've ever set up Clerk before, you're probably familiar with this. You install Clerk Next.js package, you add the clerk middleware to the proxy file, you then import the clerk provider and you add the sign in, sign up buttons and other clerk components.
But recently I've been seeing more and more of this trend of Software as a Services adding a prompt to their documentation. So you can see that it is becoming increasingly relevant for us to learn agentic coding. So let's do exactly that. I'm going to go ahead and copy this prompt and then I'm going to go into a new session in Cloud Code and I'm going to paste it here. And whenever you copy and paste prompts, make sure to at least scheme through the entire prompt to be aware of what you are instructing your agent to do.
Since this prompt came from a very reputable source, we can safely run it. But it's always a good idea to simply go through the prompt to make sure that it is what you expect it to be. And in this case, it is exactly what we need. A prompt to set up Clerk within our Next.js app router project. So I am in auto mode and I'm just going to go ahead and let it do its thing.
So before it did anything itself, it actually told me what it's going to do. It's going to install or update the clerk CLI, it's going to set up clerk in this project or it's going to scaffold a new app if the directory is empty. Since we are not in an empty directory, it's just going to add clerk to this project. And then it's going to start the app with the clerk install. Great, So this seems fine to me and I also just want to tell you that I'm using high effort in case that is relevant to you.
So I'm just going to go ahead and say proceed. Let's take a look what happened after I let it proceed. So the first thing it did is it checked whether I have the clerk CLI installed. Since I didn't have it installed, The first thing it did is it checked whether I have the clerk CLI installed. Since I didn't have it installed, the first thing it did is it globally installed the clerk CLI.
After that, it attempted to run clerk auth login. This is where some of you might have this entire setup interrupted because you needed to open a browser and actually log in. So if that happened to you, feel free to just say proceed once again or just tell it I have now authenticated with Clerk or maybe just open a brand new session and paste the entire prompt again now that you are authenticated with Clerk. So once the Clerk CLI has authenticated you can see that it used Clerk init framework Next and it uses npm as the package manager because it recognized that that is what we are using. It successfully created a proxy.ts file, sign in and sign up pages and it wrapped the layout with clerk provider.
Then it read through the layout and through the page and it also detected a chatCN configuration, which is very interesting and I'm going to show you why. So here's a cool thing. It added ClerkUI component and from ClerkUI themes it imported chatCN. So it added the appearance theme chat-cn to the clerk provider, which basically means that it has completely synchronized the theme to whatever our chat-cn theme is. It also added the expected sign-in buttons and buttons here.
My apologies and other components here. It then run clerk doctor to verify the setup which is a very cool thing. I'm assuming it's some kind of CLI tool which just ensures that everything is as expected. And since it couldn't verify that the server was reachable, what it did is it modified the proxy.ts file such as that it added the home page as a public route. I'm assuming you have something similar like this.
The end result should be a successful Clerk sign up. My apologies, setup. So now let's go ahead and read through the actual diff instead. So in the package.json I have Clerk Next.js and I have Clerk UI added here. Let's go ahead and check the proxy.ts.
So clerk-middleware create route matcher from clerk-nextjs server and we have a few public routes here. So we have the sign in, the sign up and it also added the default homepage as the public route which is I guess a smart idea so we can test whether it works or not but we're going to see if we're going to remove this or not. In here it's just a regular clerk middleware, nothing special here and just a regular config. Great! So that is the proxy.ts file which is located in the root of our application as you can see right here.
Next we have a layout.tsx update. So in here we have a lot of changes. So it imported a bunch of components from Next.js, from Clerk Next.js, it imported ChatScience from ClerkUI themes, it even imported ClerkUI themes ChatScience.css. It also added a button here. So I have some changes here which are unrelated which I'm guessing it's just my formatting so you can ignore that but let's go ahead and actually focus on adding the clerk provider here and then it just added the show component which only shows when we are signed out and another show component which is only visible when signed in.
And when it's signed in it renders a user button and when it's signed out, it renders the sign in button or the sign up button. Very, very simple. If you want to see the full code because yours looks different, this is my entire body element. Let me even zoom in so you can see the entire HTML element. There we go.
But also, source code is available and at the beginning of this chapter you can actually see how this chapter will be named and the branch which you have to access to see this exact code. So if yours looks drastically different or something is broken, you can simply copy the exact branch which this chapter is on or maybe more interesting for you to learn something point your agent to this project's open source branch for this chapter, which I'm assuming would be zero three out setup. So try and do that instead and maybe ask your agent how can we get to this state and then it will tell you what are the differences and what it has to do to achieve this state. And the other things it did is it added two page files. Those two page files are inside of the app folder, sign in and sign up, both with their nested folders inside.
There we go. Page.tsx. If you've ever set up Qlerq before, you are probably aware that this is just normal Qlerq setup but we didn't have to do anything by hand. It did all of this for us. Now it's time to check if this works or not.
So make sure you have your app running. So the port is actually running. This might happen to you as well. So what we can do here is just say, kill port 3000, or if you know a command, you can do it yourself. There we go, port 3000 cleared.
Let's go ahead and do this again, there we go localhost 3000 and there we go, So you can see we now have a header which asks us to sign in or sign up. So if I go ahead and click sign in, there we go. I have to continue with Google to continue. And once I am signed in, I have a beautiful user button here. And once I'm signed in, I have a user button which I can use to manage my account or sign out.
Just like that, in one prompt we added authentication to this project. Amazing job! Now let's go ahead and play just a little bit more with this and do something else. How about we add a test route which is supposed to be protected. So right now all of our routes are public.
So I'm just going to tell it to do the following. Add a dummy page under test name which will be protected do not make it public in the proxy.ts So add a dummy page under test name which will be protected to test if redirect works. Do not run the server. I will be testing manually. So I'm asking you to create a brand new Next.js route on the client test page and I just don't want it to be public.
So as you can see right now, I have a brand new page.tsx under the test folder inside of app. The content inside does not matter at all. So don't worry if yours wasn't generated like this. So what do we want to test now? Well, we want to test whether we can go to test.
There we go. This is what I expected would happen. I'm redirected to the login screen. So no matter what I do, I cannot enter this test page unless I go into proxy.ts and add test here. If I do that, then I'm able to see the test page.
But that's not what we want, okay? So I'm just testing whether everything truly works. There we go. And if I go ahead and log in again, there we go. Protected test page.
And if I sign out from here, I'm redirected back to the root and I cannot access the test page. Brilliant. So we can now delete this test page because we don't actually need it. And we can leave the state of the authentication as is. So even though we are not really going to have this header, I think this is a pretty good stoppage point for us.
So just like that, we've added whole authentication from one prompt. And since we are not vibe coding, we actually went through the git diff and we verified that this is what we want and that this actually works. So let's go ahead and add these changes and git push. One important thing I forgot to mention is that you should now have a .environment or .environment.local file in your project, which should now have clerk variables inside. So you should now have the next public clerk publishable key, the clerk secret key, as well as the URLs for various routes like sign in and sign up.
What's important is that after you did git commit and git push is that that file isn't present here. So this file should always be in .environment, my apologies, in .ignore. And since you did the exact same setup as me, you will have this added. So it shouldn't be available in your git repository right here. And if you go into Qlerq's dashboard, you should also see a brand new application here with the name of your project.
As you can see, browser automation is the exact name which it extracted from my package. Jason. So that will be the name of your new project in clerk too. And this will basically be your dashboard. So it's also important that you verify that you have that as well.
Your users, your organizations, your billing, your logs and all other configuration is right here. Since we have connected the railway to our GitHub repository, every new push is going to cause a redeploy. And in my scenario here, the redeployment actually fails. I'm not sure if this is going to happen to you or not, but I do wanna share the fix with you anyway. By the description of the error that was given, it looks like package lock is in some kind of conflict or it's out of sync.
So the only thing I did was run rmrf node modules and package lock.json. After that, I went ahead and run npm install and then I simply committed and then git push. And you can see that once I did that, the deployment was successful. So that was the problem if you are having the same error as me. One other thing you should add to Railway to ensure that our deployment is working are environment variables which were automatically generated using the agentic prompt.
So go inside of variables tab, click on raw editor and simply paste the entire thing inside and click update variables and then click deploy. And then you can test clerk on your production instance.