Hello,
my question is quite important for, I think, many Replit users.
2024 is coming soon and it will change many things because we will be forced to deploy any Repl that we want to remain alive while not developing on it.
But I feel Replit is not fully ready to allow people to deploy correctly, some features were planned and promised for 2024 and I still don’t see them and I’m quite afraid some of my Repls won’t work anymore.
Can you please give status on these features ?
Ability to have an Autoscale deployment for bots ? to be able to pay only for compute cycles instead of a Reserved VM for a single bot that won’t do much processes
Persistent filesystem in Deployment ? to be able to avoid using postgre database for simple projects that we now must deploy
If no persistent filesystem, what about the easy access to GCS that could be provided for deployments ? is it still planned ?
Ability to make planned processes with Autoscale (being able to start the Autoscale on a crontab), that was proposed by Replit staff but I don’t know if someone is working on it
How to use Selenium and VNC processes in deployments ? I have a scheduled process that uses Selenium and I wonder if i can convert it to Deployment … Deployments GUI says that it doesn’t work with VNC, so how can i do ?
I understand the removal of existing features of dev Repls but I must admit that the Deployments are still not at the same level and require many changes and development and I feel Deployment features are still not ready enough to migrate everything … I hope it could be delayed while devs are creating all promised features in deployments.
For cron jobs to be introduced, I imagine that 24/7 uptime could be made possible (like the previous Always On but hopefully less volatile). For now, you could always add in a webserver and ping it using uptimerobot.com (although I can’t say how short the ping interval would have to be, and I’d expect it’d have to be quite short).
Or, depending on the processes and their performance demand it may be useful to have a second server/shard for your bot (hosted on a “cheap” Reserved VM or somewhere else) which also acts as a proxy (and so, an on-demand pinger) for the reserved VM deployment.
and then you might be able to fix this with kill 1 but IIRC I had to Fork the repl
see if you can similarly configure these to be headless or use Xvfb
always on forcefully shut down. If their product literally called “always on” was poorly designed to the point where their business model couldn’t support actually delivering a product that they promised (from research, during “inactive” hours they turned it off for not just a few minutes but literally hours on end. It basically just decided when you got to have up time as if they knew when your userbase would be online). Further, IIRC they are making it so that no matter the pings, repls get forced shut after a certain period of time as before mentioned
Unfortunately we cannot deploy Discord bot with Autoscale : of course I could ping it to keep it alive with small compute cycles number but it is not possible to deploy. Bot is detected and it doesn’t deploy on Autoscale. Maybe just allowing such bots on autoscale would be enough for most usages.
And about my Selenium task, it doesn’t seem to work with headless version. I ned to simulate some actions and it doesn’t seem to work in headless mode…
I loved Always On and I would be happy to be able to keep some paid Always On dev Repls waiting for the time when i could really migrate them with persistent storage and bots ability. As always, i’m afraid Replit makes some important changes before giving enough features to replace what is removed
Always on wouldn’t work for bots in any capacity. It’s the same reason that CloudFlare workers are only used for web apps.
Constantly pinging would restart your bot constantly, with no context or listeners on past events (e.g. button listeners iirc would die), and the discord API would probably hate you for it.
Not to mention, if someone else found your server, they could easily put up another shard because of the “edge” functionality and possibly ruin things if you’re not prepared for that.
Keep in mind this is all iirc because I haven’t used discord.js in a year or so, and it changes very fast.
Sadly wouldn’t work because even webservers (and especially webservers) will have Replit.dev links, and there’d be no way to know the new dev link without some weird authentication thing.
In that case, you could maybe add a few lines of Selenium to keep your Repl online (alternative method of an UTR?)
These are not hosted on replit.dev. So, when I said that the ping interval may have to be short, it was because autoscale deployments, unlike repl.co, have been described to “sleep between browser requests”. repl.co stays alive for a while after requests. For repl.co a 15-minute ping interval is safe (and probably somewhat excessive, but I’ve had egress to waste even since when I was on Free plan).
