Creating Backup Strategies in Serverless Postgres with Laravel Cloud

Creating Backup Strategies in Serverless Postgres with Laravel Cloud

If you’re running a production application, you need a backup approach that protects your data while keeping storage costs under control.

In a dynamic environment, your app might spike one week and stay quiet the next, but with continuous backup logging, you're covered regardless of activity levels.

Laravel Cloud's Serverless Postgres maintains a continuous log of every action within your retention period (up to 30 days), allowing you to restore to any point in time during that window. This point-in-time recovery ensures you can restore data when needed without managing separate backup schedules.

Setting Up a Backup Strategy in Laravel Cloud

Laravel Serverless Postgres scales CPU and storage in real time, supports vector search and AI-driven queries, and hibernates when idle to reduce costs. One of Cloud’s fully managed database options, it offers several features conducive to dynamic cloud backup strategies:

Flexible Retention Windows

Laravel Serverless Postgres allows you to set a backup retention window between 0 and 30 days. This flexibility lets you tailor backup policies to your specific needs. Choose a backup window that works for your application and save on storage costs if your application doesn’t require backups at all.

To set up your retention window, go to Resources → Databases → Select database → Backups and choose the retention period that fits your workload.

If you need to freeze a workload while retaining backups, Laravel MySQL may be the option for you. It lets you archive a database to stop compute billing while continuing to store snapshots for later restoration. This is useful for paused projects or seasonal apps.

Autoscaling and Hibernation

With Laravel Serverless Postgres, resources automatically scale to meet demand, and databases can hibernate when idle, significantly reducing costs. If you’re new to Laravel Cloud, hibernation is enabled by default for all Starter plans.

To enable hibernation manually, navigate to your organization's Resources page, select your Serverless Postgres database cluster, click the "…" icon, select "Edit settings," configure the hibernation timeout (the number of seconds of inactivity before the database hibernates), and save your changes.

Point-in-Time Recovery

Point-in-time recovery (PITR) lets you restore your database to a specific moment, which protects you from accidental deletions, bad deployments, or corrupted data by allowing you to roll back to a known good state. Combined with automated backups, PITR gives you confidence that data can be recovered quickly without heavy operational overhead.

Laravel Cloud lets you pick a backup window based on your application’s needs, from zero retention to a maximum period of 30 days. It will keep a continuous log of all changes within the retention period you configured.

Backup & Restore Use Case Examples

  1. Automatic continuous logs with PITR daily backups with a 7–14 day retention window for active environments
  2. No retention for paused, legacy, and even side projects
  3. Restoring to a new cluster for inspection, validation, or partial recovery

Restoring never touches production directly: Cloud spins up a separate cluster so you can retrieve only what you need, reducing risk during incident cleanup.

How Your Cloud Backup Strategy Can Impact Business

By dynamically managing backups, you can achieve:

  • Cost savings: Hibernation and autoscaling reduce unnecessary expenses.
  • Regulatory compliance: Customizable retention settings ensure that data policies meet regulatory requirements.
  • Operational efficiency: Automation of backups through Laravel Cloud's managed infrastructure minimizes manual intervention, freeing up engineering time.
  • Risk reduction: PITR protects production environments from accidental data loss and broken deployments.

Tips and Next Steps

  • Assess current strategies: Evaluate existing backup policies to identify opportunities for cost reduction and increased efficiency.
  • Leverage automation: Implement automated continuous logs as part of your routine, informed by workload patterns rather than fixed schedules.
  • Review and adjust regularly: Revisit backup retention to reduce ongoing costs.
  • Test recovery plans: Periodically restore a backup to a staging cluster so you know recovery works before you ever need it.

Maintain Data Integrity, Minimize Resource Usage

A well-designed backup strategy doesn't have to be complicated or expensive. Laravel Serverless Postgres gives you the tools to protect your data intelligently through flexible retention windows, automated continuous logs, point-in-time recovery, and hibernation, so you can focus on building great applications instead of managing infrastructure.

Try it today on Laravel Cloud.

Keep reading

Laravel Cloud February 20, 2026

Laravel Cloud Incident Report: February 20, 2026

## Summary On February 20, 2026, Laravel Cloud experienced a connectivity outage lasting approximately 3 hours and 15 minutes. The disruption was caused by an [incident at Cloudflare](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/), one of our infrastructure partners, which resulted in the withdrawal of IP prefix advertisements that route traffic to Laravel Cloud services. During this time, customers were unable to reach the Laravel Cloud control panel or some of their applications hosted on Laravel Cloud. No customer data was lost or compromised, and no deployments in progress were affected. The issue was entirely network-level — applications and their underlying infrastructure remained healthy throughout. While redundancy generally exists throughout our infrastructure, we have not yet extended that same protection to our IP announcement layer. Closing that gap is now a top engineering priority. Our goal is to implement additional failover protection so that no single upstream dependency can cause a prolonged outage for our customers. ## Timeline (UTC) | Time | Event | |------|-------| | **18:42** | Laravel Cloud monitoring detects connectivity failures. Incident declared and response team assembled immediately. | | **18:45** | Cloudflare begins investigating issues with their services and network. | | **18:48** | Laravel Cloud status page updated and notification posted to Twitter/X. | | **19:09** | Cloudflare identifies impact to a subset of BYOIP (Bring Your Own IP) prefixes. Reports the underlying issue as mitigated and begins working to restore affected advertisements. | | **~19:40** | Laravel Cloud attempts to re-advertise prefixes via the Cloudflare dashboard. The option is unavailable — prefixes are locked in a "Withdrawn" state requiring Cloudflare to unlock. We communicate this to Cloudflare via our shared support channel. | | **20:50** | Cloudflare acknowledges that some customers are unable to re-advertise their prefixes through the dashboard and begins working on a fix. | | **21:57** | Full connectivity to Laravel Cloud is restored as Cloudflare completes prefix restoration. | **Total duration of impact: approximately 3 hours and 15 minutes.** ## What Happened Laravel Cloud uses Cloudflare for network services including IP prefix management via their BYOIP (Bring Your Own IP) product. On February 20, Cloudflare experienced an incident that caused IP prefix advertisements to be withdrawn for a subset of their customers, including Laravel Cloud. When IP prefixes are withdrawn from BGP, traffic can no longer be routed to the affected services. This meant that while Laravel Cloud's applications, databases, and infrastructure were fully operational, users could not reach them because the network path no longer existed. Cloudflare identified the underlying cause and advised customers to re-advertise their prefixes manually through the Cloudflare dashboard. However, Laravel Cloud's prefixes were locked in a "Withdrawn" state that required Cloudflare's intervention to unlock. This meant the suggested self-mitigation path was not available to us, and recovery was dependent on Cloudflare restoring the prefixes on their end. ## What Was Affected - **Connectivity to Laravel Cloud applications** — users could not reach their apps - **Laravel Cloud dashboard and API** — inaccessible during the outage - **Deployments** — new deployments could not be initiated ## What Was Not Affected - **Customer data** — all data remained intact and secure - **Running applications** — apps continued to run normally; they were simply unreachable - **Databases and caches** — no data loss or corruption ## Our Response Our monitoring detected the issue within minutes, before Cloudflare's own status page reflected the incident. We immediately declared an incident, assembled our response team, and updated our status page and social channels to keep customers informed. Once Cloudflare published their self-mitigation guidance, we attempted to follow it but were unable to do so due to the prefix locking issue described above. We escalated directly with Cloudflare's team and continued to monitor and communicate throughout the incident. ## Looking Forward Laravel acknowledges that single points of failure in our infrastructure can disproportionately introduce risk in our ability to manage availability of the applications we serve. We are exploring strategies to decouple and introduce redundancy in our key networking layers to create better resiliency from underlying components. We take the reliability of Laravel Cloud seriously, and we understand the impact this outage had on our customers and their users. We are committed to learning from this incident and building a more resilient platform.

Laravel Team

Laravel Cloud December 17, 2025

How We Built Laravel Wrapped

Learn how Laravel's team built Laravel Wrapped in two weeks: aggregating data across products, generating 55K AI summaries, and shipping with Cloud's speed.

Ana Tavares