Autoscale and deployment questions

Hello,
I feel the Autoscale function is a very interesting new way of having Always On Repls without paying as much as with Fixed Deployment server. But I’m not sure and I would be happy to have answers to some questions :

  • In a Python Flask app, the web server keeps waiting for a connection to render the templates. That means the server is always on but doing almost nothing. Is the Autoscale server always up and using few compute units or does it close and restart when not used ?

  • If I have a server that does almost nothing, just serving few requests every month, is it more expensive to create a Autoscale server with 2 CPU and 8GB RAM and let it do almost nothing or just take the smallest one ? I mean, with the same usage, is it less expensive to have a small server or not ?

  • My main issue about Deployment is that I can’t access the filesystem to check logs or file creations. And if the deployment crash or I need to deploy again, I lose everything. Is there a possibility to have a deployed Repl share the filesystem or use files on another Repl ? Having presistent file system with deployed Repls would be great

  • Do you plan to remove Always On feature and ask people to use Deployment instead ?

@IroncladDev I hope you’ll be able to help me :slight_smile:

Thanks

2 Likes

@fvillemin Unfortunately, Ironclad no longer works at Replit IIRC, so I don’t think he’d be able to help you here.

2 Likes

Oh, I thought he was the one to publish Deployment information
Let’s hope somebody else would be able to help me :slight_smile:

3 Likes

My name is also Conner, so I believe the person you’re looking for is @replitconner :laughing:

However, I will help you as far as I understand the deployments product to work.

TL;DR:

  • Autoscale is the most cost-efficient
  • Production environments should have an immutable filesystem
  • Always-on is being deprecated

In a Python Flask app, the web server keeps waiting for a connection to render the templates. That means the server is always on but doing almost nothing. Is the Autoscale server always up and using few compute units or does it close and restart when not used ?

Autoscale deployments will not go to sleep, even if very few requests are are fired. The amount of compute units will be at a low usage.

If you’re using flask only to render static HTML, I would suggest you switch to a static deployment to save on compute units.

If I have a server that does almost nothing, just serving few requests every month, is it more expensive to create a Autoscale server with 2 CPU and 8GB RAM and let it do almost nothing or just take the smallest one ? I mean, with the same usage, is it less expensive to have a small server or not ?

It’s definitely cheaper to create an autoscale server. If you have the hacker plan or pro plan, you get a certain amount of egress and compute units for free, which are refilled on a monthly basis at no additional cost.

Paying for only the resources you use versus a fixed amount is always way more efficient.

Shown on the Replit Blogpost is a proof-of-concept, with 2.5 million requests only costing $0.94 USD to upscale and rebase.

My main issue about Deployment is that I can’t access the filesystem to check logs or file creations. And if the deployment crash or I need to deploy again, I lose everything. Is there a possibility to have a deployed Repl share the filesystem or use files on another Repl ? Having presistent file system with deployed Repls would be great

In a production environment, it’s a bad practice to write to files in the filesystem. The filesystem of a production app should remain immutable.
Use a database provider like Supabase, MongoDB, Replit Postgres, or Neon to store production data.

Do you plan to remove Always On feature and ask people to use Deployment instead ?

As the Deployments product improves, this is the initial plan from what I remember. Always on is already being deprecated and replaced as Deployments are being adopted.

Read more on the Blog Post and the Pricing Page

6 Likes

Thanks for your very nice answer, it answers to most of my questions about Deployments

Autoscale deployments will not go to sleep, even if very few requests are are fired. The amount of compute units will be at a low usage.

Ok I have deployed a small app and will watch the usage on it. It seems to be very nice, always available and only using a small amount of compute times

Shown on the Replit Blogpost is a proof-of-concept, with 2.5 million requests only costing $0.94 USD to upscale and rebase.

Thanks for the link, very interesting

In a production environment, it’s a bad practice to write to files in the filesystem. The filesystem of a production app should remain immutable.
Use a database provider like Supabase, MongoDB, Replit Postgres, or Neon to store production data.

I understand that and I can see the same recommandations with Docker or other deployments we can do on servers.
My issue is that Repl has given us the ability to create projects really quickly. In a few hours, we can create interesting python Flask websites which get data, calculate kpis and let user interact with them. And as we now have almost unlimited fast filesystem, I would love to be able to easily use Repl Filesystem even when my Repl is deployed.
The Always On feature is going to disappear and if I want to keep some Always On projects and being able to browse through the logs and the files created by my Repls I will have to completely change the way they are done by using (and maybe paying) external tools. Too bad :frowning:

I would love having a Repl deployed in production with link to a distant filesystem which is hosted by Repl with the quota of storage I have.

Maybe it’s time for me to change my habits and think differently but it was so easy to do it with the very nice file system of Repl that I’m not happy to change. And if I have to look in the logs, the logs GUI of the deployed Repl is a bit too simple to do something serious for the moment.

Thanks anyway

4 Likes