The Replit Team
Today, we are launching Scheduled Deployments. This service allows you to schedule your applications to run at predetermined time intervals seamlessly. Specify when the application should run in natural language, and Replit will take care of the rest.
Scheduling has always been a popular use case on Replit, but configuring an application like this was difficult. Most developers set up schedulers by deploying an infinite loop that constantly checked the time to a Reserved VM. This process not only had a lot of overhead, but was also inefficient and costly.
Now, you can write something like, “Run this script every Tuesday and Thursday at 3:00 PM,” and we’ll generate the cron expression for you so that you can focus on building.
What you can build
In our closed beta, developers have used Scheduled Deployments to build applications like:
- Automated analytics reporting in Slack
- Recurring data cleanups and monitoring
- Automated announcements or messages for team stand-ups and recurring syncs
- System health checks and monitoring
- Scheduled background workers to complement existing Deployments
Pricing
Scheduled Deployments have three cost levers:
- (1) is the per-second cost of running the machine. The default machine costs $0.000028/sec. You are only billed when the job is actively running.
- (2) is the cost of the scheduler, which amounts to $0.10 per month, per Scheduled Deployment.
- (3) outbound data transfer across all Replit products costs $0.10/GiB.
If you are a Replit Core member, your membership comes with $8/month in flexible credits that can be applied towards Scheduled Deployments.
Specifications
Today, only one machine configuration is available: 1vCPU / 2 GiB RAM.
Scheduled Deployments currently have a timeout duration of 11 hours. This means the longest job you can run with this service is 11 hours. If you need to run a job longer than 11 hours, we recommend you use our Reserved VM product.
The Scheduled Deployments product does not have a concurrency limit. This means that if you have a job that runs every minute and each job takes 2 minutes, you will spawn several concurrently running jobs.
The minimum interval granularity is 1 minute. This means you cannot schedule a job to run more than one time per minute.
Future plans
Soon, we will add additional configuration options for Scheduled Deployments, such as timeout duration and machine configuration.
We’re also planning to build a robust email notification feature so you can decide if and when you get notified about Scheduled Deployment runs and failures.
We’re so excited to see what you build. To try it out, fork this example Repl, select Deploy in the header, and select the Scheduled Deployment type.
