> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> These are the docs for Sevalla, a platform for deploying applications, databases, static sites, object storage and load balancers. The dashboard is at https://app.sevalla.com.
> Bold text in steps is an exact dashboard label.
> To act on a Sevalla account, prefer the Sevalla MCP server (https://mcp.sevalla.com/mcp, see https://docs.sevalla.com/ai-agents/overview.md), then the Sevalla CLI (https://docs.sevalla.com/developer-tools/cli.md), then the REST API (https://api-docs.sevalla.com, OpenAPI spec at https://api.sevalla.com/v3/openapi.json).
> Every page index is at https://docs.sevalla.com/llms.txt.
# Migration to Oracle Cloud Infrastructure
> Sevalla is moving applications and databases from Google Cloud to OCI in waves. Check your wave and date, what changes, your new location and egress IP, and what to do.
Sevalla is moving the applications and databases it runs on Google Cloud to Oracle Cloud Infrastructure (OCI). Sevalla migrates each company for you, with all of its services at once, in waves. Your domains, DNS records and deployment workflow stay the same. What changes is the location your services run in and the IP address their outbound traffic comes from.
## Migration status
| Wave | Companies in it | Status |
| - | - | - |
| Wave 0 | Static site builds, for every company | Completed on Sep 1, 2026 |
| Wave 1 | Companies without databases, whose applications have no disk and no public TCP proxy | In progress since Oct 7, 2026 |
| Wave 2 | Companies with a database, an application with a disk, or an application with a public TCP proxy | Upcoming |
A company moves in one wave, with every service it runs. Its wave follows from what it runs: if a Wave 1 company adds a database, a disk or a public TCP proxy, it moves to Wave 2 and loses its Wave 1 date.
Static sites, object storage buckets and load balancers aren't migrated. Static site builds have run on OCI, in Ashburn, since Wave 0, and sites are served from Cloudflare's edge, so nothing else changes for them. New companies are created on OCI and have nothing to migrate.
On Oct 15, 2026, Sevalla disabled the legacy hostnames and ports of TCP proxies and database external connections for every company, whatever its wave. See [Legacy TCP proxy and external connection endpoints](#legacy-tcp-proxy-and-external-connection-endpoints).
## What changes for your services
| What | What happens |
| - | - |
| Location | Each service moves to the OCI location that replaces its Google Cloud location. Some move to another city: see [New locations](#new-locations). |
| Outbound IP address | Outbound traffic comes from one fixed IP address per OCI location instead of Google Cloud's address ranges. See [Allowlist your new egress IP address](#allowlist-your-new-egress-ip-address). |
| Domains and DNS | No change. You don't update any DNS record. |
| Internal connections | No change. Internal hostnames stay the same, and services connected to each other move together. |
| Configuration | The same image, environment variables, processes and resources run on OCI. Changes you saved but haven't deployed stay pending. |
| Deployment history | No change. The migration doesn't create a deployment. |
| Hibernated and suspended applications | They stay hibernated or suspended. A hibernated application still wakes on its next request. |
| CDN and edge cache | Sevalla purges each migrated application's cache when the migration finishes, so the first requests afterwards go to your application. |
| New services | Until your migration, new applications and databases go to Google Cloud locations and move with the rest. Afterwards you create them in [OCI locations](/platform/locations), which include Madrid, Spain and Dubai, UAE. |
## How a migration runs
1. **You get a date.** Sevalla emails your company owners, admins and developers the date and time (in UTC) of the migration, the locations your services move to and their new egress IP addresses. The [Migration notice](#check-your-migration-in-the-dashboard) in the dashboard shows the same.
2. **You get a reminder.** About 24 hours before the migration, Sevalla emails a reminder.
3. **Changes pause.** When the migration starts, Sevalla pauses deployments and other changes for the whole company until it finishes. See [During your migration](#during-your-migration).
4. **Each application switches.** Sevalla stops the application on Google Cloud, starts it on OCI, checks that it answers, then points its domains at OCI. Applications linked by internal connections stop and switch together. An application can't be reached for a short time between stopping and switching; the others keep serving from Google Cloud until their turn.
5. **Changes resume.** Sevalla purges the caches, resumes changes and emails that the migration is complete, with your new locations and egress IP addresses.
If a check fails, Sevalla moves the services back to Google Cloud, resumes changes and emails that the migration is postponed. You get a new date by email.
## Check your migration in the dashboard
The **Migration** notice in the top bar shows your wave until you have a date (**Migration · Wave 1**), then the date (**Migration · Nov 3**), then **Migration in progress** while it runs. When your migration completes, the notice disappears.
Click the notice to open **Migration to Oracle Cloud Infrastructure**. It shows:
* The three waves, with yours marked **Your wave**.
* **Schedule**: the date and time in your time zone, with the time in UTC, or the status of your migration.
* **Tasks**: what to do before your migration. The first task lists each Google Cloud location your company uses, its new OCI location and the new egress IP address.
* **Notes for our team**: messages between your team and the Sevalla migration team.
| Schedule shows | Meaning |
| - | - |
| A date and time | Your migration is scheduled. **You picked this time** or **Set by our team** says who chose it. |
| **No date yet** | Sevalla emails you as soon as your migration has a date. |
| **On hold** | Your migration is paused. Sevalla emails you when it has a new date. |
| **In progress** | Sevalla is moving your services now. |
## Pick another time
Company owners, admins and developers can move the migration, once Sevalla has emailed your company its date.
In the top bar, click the **Migration** notice.
Under **Schedule**, click **Pick another time** (or **Pick a time** if your migration has no date yet).
Click a free time. Times are in your time zone, at least 48 hours from now and inside your wave's window. Optionally, add a **Note for our team**.
Click **Move migration**.
The dashboard confirms with **Your migration moved to** and the new date, and Sevalla emails the new date to your company. If the dialog says `There are no other free times right now`, leave a note for the migration team and they find a time with you.
## Leave a note for the migration team
Notes tell the Sevalla migration team about your setup or your timing, for example a busy period to avoid or a service that needs extra care. Your team and the migration team can read them. A company keeps up to 50 notes of up to 2,000 characters each, and each user can delete only their own. Notes keep working while the migration runs.
In the top bar, click the **Migration** notice.
Under **Notes for our team**, type your note.
Click **Add note**.
## Before your migration
### Allowlist your new egress IP address
After the migration, all outbound traffic from an application comes from the single fixed IP address of its OCI location. If an external database, payment provider, mail provider, API or firewall only accepts connections from known IP addresses, add the new address to its allowlist before your migration.
Open the **Migration** notice. Under **Tasks**, expand **Prepare your third-party services for the new egress IP addresses** and copy the **New app egress IP** of each location. The scheduling email lists the same addresses. You can also find your new location in [New locations](#new-locations) and look up its address in [Egress IP addresses](/applications/networking#egress-ip-addresses).
Add the new address next to the Google Cloud ranges you allow today. Keep the Google Cloud ranges until your migration is complete.
After the completion email, remove the Google Cloud ranges from your allowlists.
An external service that only allows Google Cloud's ranges stops accepting connections from your applications as soon as they run on OCI.
### Plan around the migration
* Don't plan a release for the time of your migration: deployments are paused until it finishes.
* Make sure clients of long-lived connections, such as WebSockets, reconnect on their own. Open connections drop when an application stops on Google Cloud.
* Tell the migration team about anything that needs care, in [a note](#leave-a-note-for-the-migration-team).
## During your migration
While your migration runs, the dashboard shows a **Changes paused** notice in the top bar: **Your migration is in progress**. You can still view everything in the dashboard.
| Action | During the migration |
| - | - |
| Deploy, or change a service or setting, in the dashboard | Paused. |
| API and CLI requests that change something | Rejected with `403` and `Your company is being migrated to new infrastructure. Changes are disabled until the migration finishes.` Read requests work. |
| Deploy hooks | Rejected with `403` and the same message. |
| Git pushes | Not deployed, and not deployed later either. Deploy again after the migration. |
| Pull request preview apps | Not created for pull requests opened during the migration. Preview apps of pull requests closed during the migration aren't deleted: delete them afterwards. |
| Notes for the migration team | Work as usual. |
A deployment that was already running when the migration started finishes before any application switches.
## After your migration
* Deploy every commit you pushed during the migration.
* Remove the Google Cloud ranges from your allowlists.
* Delete preview apps of pull requests that closed during the migration.
* Check each application's location and its **Egress IP addresses** on its **Networking** tab. See [Networking](/applications/networking#egress-ip-addresses).
If something doesn't work as expected, [contact support](/support/get-help).
## New locations
Every Google Cloud location has an OCI location that replaces it. A Yes under City changes means the service moves to another city.
| Current location (Google Cloud) | Region | New location (OCI) | Region | City changes |
| - | - | - | - | - |
| Changhua County, Taiwan | `asia-east1` | Seoul, South Korea | `ap-seoul-1` | Yes |
| Hong Kong, APAC | `asia-east2` | Seoul, South Korea | `ap-seoul-1` | Yes |
| Tokyo, Japan | `asia-northeast1` | Tokyo, Japan | `ap-tokyo-1` | No |
| Osaka, Japan | `asia-northeast2` | Tokyo, Japan | `ap-tokyo-1` | Yes |
| Seoul, South Korea | `asia-northeast3` | Seoul, South Korea | `ap-seoul-1` | No |
| Mumbai, India APAC | `asia-south1` | Mumbai, India | `ap-mumbai-1` | No |
| Delhi, India APAC | `asia-south2` | Hyderabad, India | `ap-hyderabad-1` | Yes |
| Jurong West, Singapore | `asia-southeast1` | Singapore | `ap-singapore-1` | No |
| Sydney, Australia | `australia-southeast1` | Sydney, Australia | `ap-sydney-1` | No |
| Hamina, Finland | `europe-north1` | Stockholm, Sweden | `eu-stockholm-1` | Yes |
| Belgium | `europe-west1` | Amsterdam, Netherlands | `eu-amsterdam-1` | Yes |
| London, England | `europe-west2` | London, UK | `uk-london-1` | No |
| Frankfurt, Germany Europe | `europe-west3` | Frankfurt, Germany | `eu-frankfurt-1` | No |
| Eemshaven, Netherlands | `europe-west4` | Amsterdam, Netherlands | `eu-amsterdam-1` | Yes |
| Zurich, Switzerland | `europe-west6` | Zurich, Switzerland | `eu-zurich-1` | No |
| Montréal, Québec | `northamerica-northeast1` | Montréal, Canada | `ca-montreal-1` | No |
| Council Bluffs, Iowa | `us-central1` | Chicago, USA | `us-chicago-1` | Yes |
| South Carolina, USA | `us-east1` | Ashburn, USA | `us-ashburn-1` | Yes |
| Ashburn, Virginia | `us-east4` | Ashburn, USA | `us-ashburn-1` | No |
| The Dalles, Oregon | `us-west1` | San Jose, USA | `us-sanjose-1` | Yes |
| Los Angeles, California | `us-west2` | San Jose, USA | `us-sanjose-1` | Yes |
| Salt Lake City, Utah | `us-west3` | Phoenix, USA | `us-phoenix-1` | Yes |
| Las Vegas, Nevada | `us-west4` | Phoenix, USA | `us-phoenix-1` | Yes |
| Osasco, São Paulo | `southamerica-east1` | São Paulo, Brazil | `sa-saopaulo-1` | No |
| Santiago, Chile | `southamerica-west1` | Santiago, Chile | `sa-santiago-1` | No |
A company with services in more than one Google Cloud location moves to the OCI location that replaces each one. For every OCI location and its egress IP address, see [Locations](/platform/locations) and [Egress IP addresses](/applications/networking#egress-ip-addresses).
## Legacy TCP proxy and external connection endpoints
On Oct 15, 2026, Sevalla disabled the legacy hostname and port of every TCP proxy and database external connection, for all companies, migrated or not. Since then, each TCP proxy and external connection works only on its new hostname and port. Clients that still use the legacy ones can't connect.
The deadline didn't depend on your migration date, and the TCP proxies and external connections themselves stayed enabled.
To fix a client that stopped connecting on Oct 15, 2026:
* **TCP proxy**: open the application's **Networking** tab and copy the hostname and port of the TCP proxy. The alert **Your TCP proxy endpoint has changed** lists the legacy endpoints under **Show legacy endpoints**, so you can tell which client used which. See [Networking](/applications/networking).
* **Database external connection**: open the database's **Networking** tab and copy the external connection's hostname and port. If no new hostname shows, enable the external connection there to get one. See [Connect to a database](/databases/connect).
Internal connections between your services were never affected.
## Frequently asked questions
No. OCI becomes the infrastructure under the whole platform, so every company moves. You can [pick another time](#pick-another-time) inside your wave's window.
Sevalla emails your company that the migration is complete, with your new locations and egress IP addresses. The **Migration** notice disappears from the top bar, your services show their OCI location, and each application's **Egress IP addresses** show a single address.
They move in Wave 2, with applications that have a public TCP proxy. Wave 2 hasn't started. Before it does, Sevalla emails each Wave 2 company its date and any extra steps, and the **Migration** notice lists them under **Tasks**.
The email says why: your company now runs a database, a disk or a public TCP proxy and moved to Wave 2, the migration plan changed, the migration couldn't start at the planned time, a check failed during the migration, or the migration team postponed it. Sevalla emails the new date when there is one.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.