From the course: Replit 101: From Prompt to Product
Publishing your app
At the beginning of the course, I said I would take you all the way from prompt to published app. And we are now at the published stage. If you've been following along since the beginning, you now have a fully functioning app of your own design that you can put onto the internet so other people can use it. And that's what happens when you publish an app. So far, we've been working in a development environment. That means we've had a database, a server, server, everything running inside a container in Repl.it that only exists for as long as we're working on it. If you look in the interface here, you'll see there's this Stop button up next to the name of the app. And if I hover over it, it says Stop App. Agent is running it. If you click on that button, you stop the project, stalling out the entire development process. And now you're not incurring any cost, but the app also does not run anywhere. When you publish the app, Repl.it will set up a whole new app on different servers with different backend databases, different security keys and features to ensure nothing goes wrong, and an entirely separate setup. That app then lives on its own in a published server. And anytime you work on the app, you'll be working on it in a development environment and then pushing any changes over to the production server. The actual publishing process is straightforward. You go into your app, click on publish. From here, you set the primary URL. So this will be something.replit.app. You can choose what it suggests or change it to something else. Below, you can choose how you want to publish the app. So by default, it's published to the public, meaning anyone can get access to it. If you have a team, or you're in a company, or you're in a team account, or you have other people in your project, you can publish it so it's private only to members of your team. And you can also choose to add a made with Repl.it badge if you want to. Below, there are some additional settings. You can set up the deployment type, you can set up the machine configuration, you can change the build command. All of these are developer-centric options that may be relevant for specific implementations, but in most cases, you should just leave alone. And at the very bottom, you have the production database settings where you either create a new production database or move the development database data over to the production database. That last part is important because if you built out an app using real data in development, you want to migrate that data over. You don't want to start fresh without any data. So let's publish the app. I'll click publish. And now Repl.it goes through a process to ensure that everything is done right. First, it provisions the necessary services on the Repl.it servers, setting up a database, setting up the backend, spinning up a virtual machine, doing all those pieces. Then it runs a security scan of all the code in the app to ensure everything is done correctly, that the app isn't leaking passwords and keys, that everything is working as it's supposed to. Then it runs the build process to actually put the app together and the backend together and make everything work properly. It bundles it all up into a small package so that it's easy to deliver off the web. And finally, when publication is complete, you get this overview. From here, you can see the status of the published page. The visibility is currently public. Here's the domain with the QR code. From here, you can also buy a custom domain to point at the domain. So you're not using the Repl.it domain, but your own domain. It tells you the type of machine that it's running on, that it's set to auto-scale, and you can manage these different settings. In this view, you also have logs telling you what's going on on the site. You have analytics telling you traffic on the site. You have resources that show you how much work the virtual machine is doing. You can see any mapped domains that exist for the site, and you can manage the site itself. Now, if we go back to Overview, you'll notice here there's a button that says republish. That's because even though you've now published a site, you can still keep working on it. Still sitting over here in preview, you can continue chatting with the agent, make changes, and as you do so, you click republish to push your changes over to the production site. This is an important step because as you publish a website or a web app, you'll notice things that need to be changed and you can then come back to Repl.it and make those changes and push them out into production to make them live to everyone. Now that you've published the app, you can go to the homepage for Repl.it and go to Published App to see it listed. From here, you can visit the app directly or click into it to go back to the Repl.it editor. You go to Overview, and from here, you can go back to the Preview and work on the app. And because it's published, you can now monitor it under Usage. And this is a good reminder that as you're working with Repl.it, you should check your usage every once in a while to make sure you still have credits left, to make sure that none of your apps are burning credits really fast, and to get an understanding of what is happening between all your apps and your agent use. Scrolling down here, you can see here under the published apps, you can open up these dropdowns to see which apps are using credits, how much they cost, what they're actually doing, and so on. So this is a page you need to pay attention to. And as I explained in the very beginning of the course, this is why you need to set your usage limits so you don't accidentally end up spending a lot of money on the apps you've built.