Create new Expo project with pnpm
To create a new Expo project template, run: pnpm create expo-app my-app --template default@sdk-57
eas-hosting
132 notes in this subject, read out of this brain and free to use. This is page 1 of 3.
Create new Expo project with yarn
To create a new Expo project template, run: yarn create expo-app my-app --template default@sdk-57
Export command must run before each deployment
You must re-run the export command every time before deploying to ensure your web project is up to date.
EAS CLI check login status
To check whether you are logged in to an Expo account, run: eas whoami
First eas deploy command behavior
The first time you run eas deploy, it will prompt you to connect an EAS project if you haven't done so yet, and ask you to choose a preview subdomain name.
EAS Hosting account requirements
EAS Hosting is available to anyone with an Expo account, regardless of whether you pay for EAS or use the Free plan. You can sign up at expo.dev/signup. Paid subscribers can create more deployments, have more bandwidth, storage, and requests, and may set up a custom domain.
Create new Expo project with bun
To create a new Expo project template, run: bun create expo my-app --template default@sdk-57
Export web project with yarn
To export your web project into a dist directory using yarn, run: yarn expo export --platform web
Export web project with bun
To export your web project into a dist directory using bun, run: bun expo export --platform web
Export web project with pnpm
To export your web project into a dist directory using pnpm, run: pnpm expo export --platform web
Deploy to EAS Hosting
To publish your website to EAS Hosting, run: eas deploy
EAS Hosting IP identification headers
EAS Hosting provides three headers to identify the IP address of the user's device: Forwarded contains a comma-separated list of semicolon-separated parameters where each entry represents a proxy that forwarded the request, with the first entry's for parameter likely being the original client's IP address; X-Forwarded-For contains only a comma-separated list of IP addresses representing each proxy that forwarded the request; X-Real-IP contains only the original request's IP address. To retrieve the IP address of the user's browser calling an API route, read the X-Real-IP header.
Example: Reading request headers in EAS Hosting API route
```js export async function GET(request) { request.url; // 'https://my-app--or1170q9ix.expo.app/' request.headers.get('Origin'); // 'https://my-app--staging.expo.app/' request.headers.get('X-Forwarded-Host'); // 'my-app--staging.expo.app' origin; // 'https://my-app--staging.expo.app/' } ``` This example shows how to access the deployment URL in request.url and the incoming client URL in Origin and X-Forwarded-Host headers.
Example: Reading client IP address from request headers
```js export async function GET(request) { const ip = request.headers.get('X-Real-IP'); } ``` This example shows how to retrieve the IP address of the user's browser calling an API route by reading the X-Real-IP header.
EAS Hosting runtime platform
EAS Hosting is built on Cloudflare Workers, a serverless platform for APIs designed for scalability, reliability, and global performance.
Unsupported Node.js modules
The following Node.js modules are not supported in EAS Hosting: node:punycode, node:readline (non-functional JS stubs, workers have no stdin), node:worker_threads (non-functional JS stubs, workers do not support threading).
Partially supported global functions
require is partially supported in EAS Hosting. External requires are supported but limited to deployed JS files and built-in modules. Node module resolution is unsupported. require.cache is not supported.
Partially supported Node.js modules
The following Node.js modules are partially supported in EAS Hosting: node:console (provided as partial JS shims), node:dns (Resolver unimplemented, all DNS requests sent to Cloudflare), node:fs (supported with in-memory filesystem), node:http (supported except server functionality), node:http2 (partially supported, server functionality unsupported), node:https (supported except server functionality), node:module (SourceMap unimplemented, partially supported otherwise), node:net (Server and BlockList unimplemented, client sockets partially supported), node:os (JS stubs providing mock values matching Node.js on Linux), node:tls (supported except server functionality), node:tty (JS shims redirecting output to Console API), node:trace_events (non-functional JS stubs).
Future Node.js compatibility expansion
More Node.js compatibility shims may be added to EAS Hosting in the future, but all Node.js APIs not documented in the official reference are not expected to work. Code and dependencies should not rely on undocumented Node.js APIs being provided.
Cloudflare Workers runtime architecture
Cloudflare Workers runs on the V8 JavaScript engine, the same engine powering Node.js and Chromium. Instead of running each request in a full JavaScript process, Workers run requests in small V8 isolates, which are micro-containers within a single JavaScript process.
PR preview workflow trigger conditions
The PR preview workflow runs whenever a pull request is opened, reopened, or synchronized.
PR preview workflow file location and name
The PR preview workflow file should be created at .eas/workflows/pr-preview.yml.
PR preview workflow configuration
A PR preview workflow with the filename pr-preview.yml uses the following configuration: name is 'PR Preview', trigger is 'pull_request' with empty params, and it contains two jobs. The 'deploy' job has type 'deploy' and name 'Deploy PR Preview'. The 'comment' job depends on the deploy job (needs: [deploy]), has type 'github-comment', and automatically discovers the deployment and posts its details to the pull request.
Production deployment workflow file location and name
The deployment workflow file should be created at .eas/workflows/deploy.yml.
Production deployment workflow configuration
A production deployment workflow with the filename deploy.yml uses the following configuration: name is 'Deploy', trigger is 'push' on the 'main' branch, job type is 'deploy', job name is 'Deploy', environment is 'production', and params contains prod: true. This workflow automatically deploys your website whenever a commit is pushed to main or a PR is merged.
When not to use EAS Hosting
Do not use EAS Hosting for mobile-only projects with no web component. Do not use EAS Hosting if you require full Node.js runtime compatibility, as EAS Hosting uses Cloudflare Workers runtime with only partial Node.js support. Do not use EAS Hosting if you already have established web infrastructure that meets your needs.
Example EAS Workflows deploy job configuration
Example deploy job configuration for EAS Hosting: ```yaml jobs: deploy_web: type: deploy environment: production params: prod: true ``` You can also make production conditional based on branch: ```yaml jobs: deploy: type: deploy params: prod: ${{ github.ref_name == 'main' }} ```
Deploy web app with EAS Hosting
After exporting your web project, run eas deploy to publish your web app. Once deployment is complete, the EAS CLI will output a preview URL to access your deployed web app.
EAS Hosting use cases
Use EAS Hosting when you need to: deploy a web build without setting up a separate hosting provider, use API routes or server functions in your Expo Router app, maintain consistent deployment workflows across Android, iOS, and web, automate deployments using EAS Workflows, or use built-in monitoring for server-side code crashes, logs, and requests.
Cache-Control header for API routes
API routes can return Cache-Control directives in response headers that will be used by EAS Hosting to cache the response appropriately. For example, a response with headers { 'Cache-Control': 'public, max-age=3600' } will cache the response for 3600 seconds before invoking the API route again.
Cache-Control directive syntax
Cache-Control headers are strings of comma-separated settings. Directives that accept parameters use an equal sign followed by the parameter value, such as max-age=3600. Directives without parameters are listed without a value, such as public. Multiple directives are separated by commas, for example: public, max-age=3600.
Request directives to skip cached responses
no-store, no-cache, or max-age=0 sent as request directives will skip cached responses and always force EAS Hosting to ignore its request cache.
min-fresh request directive
The min-fresh request directive will skip a cached response if it is older than the specified value. For example, min-fresh=360 will prevent a cached response from being returned if it has been cached for longer than 360 seconds.
Request directive: only-if-cached
The only-if-cached request directive will only return a response if it is cached. If not cached, it aborts the request with a 504 response with a must-revalidate directive.
Cacheability directives: public, private, no-store, no-cache
Public: Indicates any cache including EAS Hosting may store the response. Private: Indicates the response is intended for a single user and may only be cached by a browser. No-store or no-cache: Indicates the response may never be cached or stored. Example: 'public, max-age=3600' allows EAS Hosting to cache for 3600 seconds, while 'private, max-age=3600' only allows browser caching.
Automatic public cacheability for GET and HEAD requests
Responses to requests with no Authorization header set and that are either HEAD or GET request methods are automatically considered publicly cacheable by EAS Hosting.
CDN-Cache-Control header for EAS Hosting-specific caching
The CDN-Cache-Control response header can be used to customize caching for EAS Hosting separately from browser caching. When this header is used, it implicitly adds public to the directives and forces EAS Hosting to cache the response according to the specified directives. Example: returning headers with 'Cache-Control': 'no-store' and 'CDN-Cache-Control': 'max-age=3600' prevents browsers from storing the response but allows EAS Hosting to cache for 3600 seconds.
EAS Hosting data sampling for high-traffic deployments
When a deployment receives high traffic, EAS Hosting downsamples the recorded data. This means fewer individual data points are recorded and you may not see individual requests, logs, and crashes listed one by one. However, statistical counts such as total number of requests or crashes are estimated to still reflect all requests proportionally.
EAS Hosting requests inspection
Requests can be viewed at two levels: project level at https://expo.dev/accounts/[accountName]/projects/[projectName]/hosting/requests and deployment level via Hosting Deployments > select a deployment > Requests tab. The requests list shows metadata per request including status, browser, region, duration, and other details. All requests to the service are included, including requests to API routes.
Request ID lookup via Cf-Ray header
All response headers include a Cf-Ray header (format example: 8ffb63895cf6779b-LHR). The first part of the Cf-Ray header is the request ID. You can look up a request on the EAS dashboard using this ID via the filters in Hosting > Requests. The request ID is also displayed on service-level error pages.
EAS Hosting crashes inspection
Crashes are uncaught errors thrown during request handling that prevent a response from being returned. Crashes can be viewed on the Hosting crashes page at https://expo.dev/accounts/[accountName]/projects/[projectName]/hosting/crashes. Crashes are automatically grouped, so similar crashes appear as a single line item. Crash details display the stack trace and metadata for both the first and last known occurrence of each crash.
EAS Hosting logs inspection
All logs from API routes and server functions (console.log, console.info, console.error, and so on) are recorded at the deployment level. Logs can be accessed by navigating to Hosting deployments, selecting a specific deployment, and clicking the Logs tab.
Promote existing deployment to production by ID
An existing deployment can be promoted to production using its deployment ID with the command: eas deploy:alias --prod --id={deploymentId}
Aliases are unique per project
Aliases are unique per project. If you choose an alias that was already in use, it will be re-assigned to the new deployment.
Create deployment with alias using EAS CLI
To create a deployment and assign it to an alias, use the command: eas deploy --alias {alias-name}. For example, eas deploy --alias hello will create a deployment with a standard URL and an alias URL at https://my-app--hello.expo.app/
EAS Hosting deployments are immutable
Each deployment to EAS Hosting is immutable and cannot be changed after deployment. Deployments are accessible via a unique deployment URL consisting of the preview subdomain name and the deployment ID. Once deployed, they will always remain accessible and identifiable using their deployment ID.
Multiple aliases per deployment
A single deployment can have multiple aliases assigned to it.
EAS Hosting uses SNI, not dedicated IP addresses
EAS Hosting uses SNI (Server Name Indication), which means that IP addresses are shared and are not dedicated to a single project.
Arbitrary alias names for environments
Aliases can have arbitrary names. For example, you can create a staging environment by creating an alias called 'staging' and assigning a deployment to it.
Preview URL structure with preview subdomain
A preview subdomain name is a prefix used for the preview URL. For example, if you choose 'my-app' as the preview subdomain name, your preview URL would be https://my-app--{deployment-id}.expo.app/ where the deployment ID is a unique identifier for that specific deployment.
Promote deployment to production with --prod
A deployment can be promoted to production using the --prod option: eas deploy --prod. This makes the deployment available at the production URL like https://my-app.expo.app/
Production URL structure with preview subdomain
If you choose a preview subdomain name like 'my-app', your production URL will be https://my-app.expo.app/
Deployment ID customization and defaults
Each deployment has a unique deployment ID that is identifiable and can be customized, but will be a random string of letters and numbers by default.
Preview subdomain name setup
To activate EAS Hosting for a project, you must choose a preview subdomain name. This can be done via the Hosting section of your project on expo.dev, or you will be prompted to choose one when creating your first deployment using the EAS CLI.
Assign alias to existing deployment
Aliases can be assigned to an existing deployment by using the command: eas deploy:alias --id={deployment-id}. The deployment-id is the ID in the preview URL.
Custom domain is a premium feature
Setting up a custom domain in EAS Hosting is a premium feature and is not available on the free plan.
Custom domain assignment prerequisites
To assign a custom domain in EAS Hosting, you must have an EAS Hosting project with a production deployment. The custom domain will always load the production deployment. You also need to own a domain name that you want to use.
One custom domain per project
Each EAS Hosting project can have exactly one custom domain, which is assigned to the production deployment.
Custom domain supported types
EAS Hosting supports both apex domains and subdomains as custom domains. If you own example.com, you can assign either example.com as an apex domain, or anything.example.com as a subdomain.
Custom domain DNS records required
Three DNS records must be configured for a custom domain: a Verification TXT record to prove domain ownership, an SSL CNAME record for Domain Control Validation (DCV) to a certificate authority, and a third record (A record for apex domains or CNAME record for subdomains) that points the domain at the EAS Hosting production deployment.