Transcript
Introduction & Overview
0:00 · hey it’s Matt with repet here and if you’re trying to deploy an application you’re in the right place because today we’re going to talk about the four different types of deployments that we have on repet and we’re going to go over each type in detail we’re going to talk about what apps make the most sense for each type and then in cases where you could go either way specifically with Reserve VMS or Autos skill deployments we’re going to discuss the pros and cons of each approach and maybe there are some things you could do to deploy uh your applications with one but it might not make sense um so we’re going to go over all of that first I’m going to walk through the four different types uh and then I’m going to present a decision tree which you’ll be able to find in the comments uh in the links below that’s exactly the same logic I would use when I’m trying to figure out how to deploy my application so my goal is that by the end of this video you’re pretty confident about how you deploy any project that you’re cooking up and I’ll link to some other tutorials that might help you with more complex deployments but let’s jump right into it so our first type of deployment is a static deployment and the name is pretty selfes sctive static deployments are called Static because they compile to a set of static files often these are HTML or JavaScript files um but when I say static I just mean they’re being run by the client they’re being executed by your browser and browsers most commonly serve HTML files and execute JavaScript files um now for example something like running streamlet is not an example of of a static file because in order to serve uh you know a python uh application like streamlet um you have to to run streamlit main.py so you’re actively running a command against python which is not live in the browser now you’d be very surprised the different types of things that you actually can run in the browser because browsers support running JavaScript client side for example some really cool demos with 3js I’ve shared similar demos some really cool uh new projects from the Transformers JS Library um which involve running llms client side are all becoming more possible so don’t kind of like throw shade at static deployments for not you know having a client component but what a static deployment is is a set of pre-compiled static files the thing about that is that they’re very fast to deploy you can deploy them in quite literally seconds on repet uh and if you’re looking for a parallel here maybe you’re still trying to bridge the gap as to what a static deployment is think GitHub Pages if you can deploy it on GitHub Pages you also can deploy it as a static deployment on repet our requirements for static deployments are a public directory and a build command the public directory is where the output of the build command goes so I think for Frameworks like V that’s uh dissed uh for some under the Frameworks it might be build it’s just basically if you run like mpm run build what’s the directory that those static files get output to and then the build command follows from that right npm run build would be your build command if you’re building to that directory so pretty straightforward static deployments are really great my blog is deployed as a static deployment um but they only serve a limited set of deployments if you have a server if you have something that’s actively running a framework this is not the deployment for you but we’re going to go on to our next deployment which is also pretty simple pretty straightforward and those are scheduled deployments scheduled deployments as the name would suggest are scripts that run on a schedule and these could be great for fetching scraping updating data they could be great for any number of things that you need executed maybe sending a message to a slack Channel um or uh performing an action on a set Cadence and the great part about scheduled deployments is that they’re going to execute once and then they’ll be off so if you think about you know how much compute you’re using it’s likely lower than if you just ran something constantly because scheduled deployments ex are executed and then shut down they don’t really have a UI the UI wouldn’t be available for the user so if you need a scheduled uh job as a part of some larger application you might think about multiple deployments or folding that scheduled job into uh another type of deployment now if you’re familiar you can think about a scheduled deployment like a Cron job we actually use the KRON syntax when defining the scheduled deployment if you’re not familiar with that don’t worry because we compile natural language to that syntax we make it really easy for you to Define exactly how often you want the thing to run or Define KRON syntax because you know what that is so requirements for a schedule deployment we have a build command completely optional we have a run command for example if you wrote a python script that went out and fetched data and it was in Main .p your run command would be python main.py then we have a timeout uh for example if you’re doing some kind of fancy script that you know doesn’t necessarily work every time or or uh you want to be terminated after a certain number of minutes or you know a certain number of seconds you could provide an optional timeout but really all you need for this one is a run command it’s pretty straightforward you’re just running a script so now we’re getting into the two more complex type of deployments or I would call them complex because it’s easy to mix them up but the first of which is reserved VM and a reserved VM stands for a reserved virtual machine again the name is very descriptive here is just an always on sort of machine that’s running in the background that you deploy your app to so if I had python you know main.py and I wanted it to run continuously I deploy it to a reserve em it’s going to run and execute Python main.py and it’s going to keep that command alive until I tell it not to so in a reserve VM the machine is always on what that means is that because the machine has the same size you’re defining the size of the machine when you deploy and it’s always on you’re going to have a fixed cost it’s going to cost a certain amount of money every month you know exactly what that is it’s not going to change now there are downsides to that right if you define a certain number of resources and say your app blows up or you build an API and deploy it and the API blows up or it’s doing something really hard and you didn’t Define enough resources your users are probably going to experience like degraded performance it’s not going to be good so uh you have to be careful when you’re allocating resources to be sure that you know you’re you’re giving your reserve VM enough to execute on the jobs that you want it to the requirements for a reserve VM are a optional build type uh a run command you need the Run command um an app type so you’re either defining a web server or a background worker uh you know that just determines if your app has like an exposed front end for example if you wanted to deploy say a Discord bot or a slackbot those would be background workers because they don’t have a UI they’re actually really good choices for Reserve VMS because uh if you think about most of those Bots they need to listen um constantly you know like if a user is to put a slash command in slack or put a command in Discord um and that command is going to ping you know your server and then the server is going to do something and it’s going to respond to the command and those servers need to be always on they need to be listening uh for those commands so Reserve VMS are really great for that often times you know the types of computations or work that you’re doing for those Bots isn’t super intensive um now right you could also deploy if your slackbot is not responsive to the user and it’s just sending a message you know every 20 minutes every day that could be a scheduled deployment as well it would be cheaper that way um but if you need something that’s always on you want to go with a reserve VM and finally a port configuration this is mostly optional because if your app runs in repet we’re going to configure the port for you so you don’t really need to worry about that um unless you’re running into problems deploying the app or you haven’t actually run the app and rep replit or configured the port but assuming that you said everything up correctly this shouldn’t really be required so this brings me to our final type of deployment autoscale deployments autoscale deployments are scaling servers they can scale up or down to accommodate varying amounts of traffic for your application so think about it like if you post something on Twitter maybe you you build an app and you’re trying it out you don’t know if anybody’s going to use it and you just like put it on X the the platform formerly known as Twitter um and it goes viral and a million people are coming to view it if you configure autosale deployments properly you can scale up the number of machines automatically as people come to your site uh and if you select the proper machine resources this is kind of like a trial and error logic thing based on what your app does right uh but if you configure the resources properly um there shouldn’t really be any Interruption as all these people come to your application because we’re going to spawn multiple instances and scale this appli up to accommodate all those people so autoscale deployments are really powerful that way and the flip side to that is that um if nobody use your application that’s most stuff I post on on X honestly right if I don’t need to be worried about anything going viral you know I need to be worried about posting all this stuff and then getting build for it because nobody views it and it’s running all the time like if I spawned a bunch of resered VMS they’re always on they’re running all the time but with autoscale deployments if nobody looks at your application it’s going to scale down to zero which means that it just kind of like shuts off it’s like kind of like in sleep mode if you think about like your your laptop goes to sleep your deployment goes to sleep what that means is that if nobody’s looking at your application and then one person comes to see your application there might be a small amount of time where it has to wake up very much like a computer waking up uh but often it’s one or two seconds it’s unnoticeable and then it’s going to stay warm for quite some time uh while other people use the application that’s really great because it means I’m not getting build when it’s asleep and that’s great for you know like cost purposes there are some pros and cons to that we’re going to talk about those uh a little bit later in the video for an auto scale deployment you optionally need a build commands you need a run command obviously uh and you need a port configuration again the port configuration is likely already set also note that there are many more configuration options for the type of machine when you’re deploying via autoscale because you can pick the maximum number of machines that we scale horizontally you know for example you could scale one machine or you could scale five um as well as the actual power for each machine that’s being spawned so pay attention to that when you’re you’re building your application that’s largely dependent on what your app is doing so I’ll leave that to you now one additional thing before we dive into my decision tree I want to talk a bit about autoscale versus reserved deployments uh because this is something that’s confusing it was confusing to me when I first learned about the concept so I want to try and break it down if you’re saying hey I know this thing isn’t static I know it’s not a schedule deployment it should probably be autoscale or reserved I just really don’t know which one hopefully the sort of cost certainty and wakeup uh explanation can help you decide that but if not I’m going to break it down a little bit more so again autoscale deployments are really for scaling servers and they have a variable cost right but reserved deployments are always on they could be like a web server or background worker uh and they’re going to have a fixed cost so you get cost certainty with those we’re going to talk a bit more in depth like technically about what that looks like but the anal I like to use here is a nest thermostat or a greenhouse right if you have an apartment I’m in an apartment now what a coincidence you probably want a smart thermostat because your smart thermostat is going to keep the apartment cool when you’re there or keep it warm when you’re there and then when you leave it’s going to save energy and that saves you money especially in California Energy prices are crazy here what’s the deal anyway uh your smart thermostat is going to be intelligent and save you money that means that when nobody is using the space you’re saving money when people are using it you’re you’re you’re spending money but that’s the whole point right to be comfortable if I had 40 people in here you know this assumes I have friends you know for the sake of this video Let’s just assume I have some friends if I had 40 people in here if I managed to convince 40 people to spend time with me this apartment would probably get pretty warm and my Nest Thermostat would sort of kick into gear and cool the apartment down that’s like an autoscaling appointment as more people come in you’re going to kick up those servers they’re going to spin up multiple instances and the the workload shouldn’t be interrupted at all and so in that sense it’s really great now Matt you’re probably saying okay well like that sounds perfect why the heck would I ever want the alternative a reserve VM well I also have plants in here you might not be able to see them in the frame this is one such plant those plants you know like if you think about the optimal way to grow plants you don’t want the temperature to be like going all over the place right you want the temperature to be stable and that’s the whole concept of a greenhouse uh so for other things you want a constant temperature for example you have a slackbot or a Discord bot it just needs to be running all the time you don’t want it to scale down to zero because it’s actually watching for some message similarly if you had an API right the whole idea behind an API and application programming interface is that at any time someone could call that API maybe you have another application that’s calling the API maybe you’re using something uh like nextjs which has both client and server side code nexts uses apis if you dig into uh like app router and things like that those apis have to be running all the time otherwise the client might try to call the API and if it’s autoscale deployment starts to spin up from zero and then it takes there’s some latency there right and that’s a non-optimal experience so the analogy I like to use here Auto scale deployments kind of like a NE Nest Thermostat they’re going to keep you cool even if there’s a lot of stuff going on uh sometimes you need a constant temperature Reserve VMS more like a greenhouse okay that’s my nerdy analogy that I just really love for some reason we’re going to get into a decision tree if you’re still watching this video I assume you have more questions so this will cover basically every scenario I could come up with when you’re trying to deploy okay so here’s my decision tree this is how I think about building on repet we’re going to start with the simpler Solutions first and we’re going to dig into the more complex stuff you’re deploying an app or website yeah actually no I’m not deploying an app or website what am I doing though I am building an API if you’re building an API just deploy a reserve VM it’s always on people will be able to access your API um you just need to Define uh the parameters you’d want to use a reserve VM and not an Autos scale deployment because of that cold start uh problem I described earlier where if nobody’s using your API it’s going to shut off and you don’t want that if you’re deploying an API if you’re deploying a bot I would put Bots under the category of an API um or other type of infra like that that has to listen for some event Reserve easy answer um also no I’m running a script we talked about this scheduled jobs if you’re running a script it’s not a bot it’s not a website you just want to run something on a Cadence it doesn’t need to be running all the time it doesn’t have to accept user input it just needs to run every day at a certain time you deploy a scheduled job okay let’s get to the more interesting part of this decision tree you’re deploying an app or a website yeah yeah all right cool let’s start on the right here my app needs a server or Pro program that’s running continuously for example if I ran something like python main.py or streamlet main.py or NP or you’re running you know like next Uh something’s being continuously run now there are a couple options here right this is kind of what I was talking about earlier we did the auto scale versus reserved type deal uh same thing here you could deploy this thing as the auto scale deployment you could deploy it as a reserve deployment there’s another uh solution we’re going to talk about in a little bit as well um so first option I want to be able to scale up quickly to handle large amounts of requests um and I’m okay with variable cost and minimal warm-up time you might be you might already know what I’m referring to here um so that’s one option the other sort of option is my app needs to be running constantly with access to consistent resources I want cost certainty okay we’re going to assume uh my hypothetical app is on the left and if it’s on the left and if it meets these criteria maybe it’s a server it’s using httt HTTP http2 websockets or grpc or I want to try out multiple ideas without spending too much this is kind of like the X example that I mentioned right I could post 100,000 apps if nobody uses any of them I’m not getting buil for them um then we’d want Autos scale deployments cool now Flip Flip that over to the other uh sort of option here maybe I want a wrong Lan con connection I want to deploy a bot I want to run a background activity outside of request handling okay so uh in in addition to just handling the user requests I want to be running something in the background I want this thing to be constantly doing something um my app is not a server uh my app does not tolerate being restarted easily one of the things about autoscale deployments is that if it scales down to zero your app’s going to restart and this gets us into like persistent data within reples the repple storage is not persistent it’s actually a snapshot of your application when you click deploy so think of all the files and directories in your app when you click deploy that’s snapshotted and deploy if you have like a SQL light database in there SQL light database is not going to persist that’s why you’d need to use persistent data in the form of a postgress database that’s we have options for a key value database we have options for our object storage which we also have options for um but if your app does not tolerate being restart easily uh Reserve VMS are a great choice for you and all of these tie into Reserve vmss cool let’s continue down the left here we’re actually getting through this pretty well my app is entirely client side code we’ve talked about this if your app is running on the client that can actually be some pretty cool stuff right you could have some pretty neat visualizations I’ve actually shared a few it can be deployed on GitHub Pages it can be deployed on cloud Fair Pages it’s a it’s a static site use static deployments really fast really cheap really simple easy solution there okay let’s get to the fun one my app is a mix of client side and server side code for example you have a front end you have a back end you actually have options dog what’s up dog so the easy solution if you don’t care run it as a monole reserve VM what do I mean when I say monor repple stuff all that that jazz in one repple and just run it we’re just going to spin up two services at the same time you have to play around with this a bit I have a tutorial actually on how to do this so uh rather than just taking my word for it go watch the tutorial which I’ll link in the description below uh and just deploy it as a single reppel that’s a simple solution um if your app is like a next app that just kind of has those Services baked in it’s actually really straightforward it only requires one command now the more complex or more advanced solution would be to spin up two reppel and have them talk to each other for example say you have a server you could build out a reppel that’s a server deploy it now you have a reel that’s a server it’s listening on some port at some address the cool thing about development environments right is because a develop environment is exposed to the web while you’re developing you just use that development environment um as the server basically and you can develop live both the server and the front end it’s kind of neat um and you deploy that server and then you have your front end and you deploy the front end separately advantages here well you could basically segment the parts that you’re getting built for so maybe I only want to be build for this like reserve VM and then I want to offload the traffic like all the people visiting my app like most of it’s client side so we want their client to handle most of the workload and that way I’m not paying for it but then when they make calls to the server when they’re hitting the API we want to return data dynamically I have a tutorial on how to do that I have a tutorial on how to sort of deploy a static front end with a dynamic backend thus reducing the cost offloading most of the work to the client saving you money maybe a little bit more efficient a different setup slightly more complicated that’s kind of the gist of it but those that’s my decision tree I’m going to make this available to you I’m going to put this in our document ation um hopefully that kind of helps you decide uh how you go about choosing what type of deployment you want to share with the world um hopefully this video has helped you understand the different types of deployments on repet and when you use each type um again I’m Matt with repet this has been an introduction to the types of deployments we have and all of our options for taking your idea and putting it live on the internet but until next time peace e