Is Self-Hosting Next.js Apps a Good Idea?
It’s hard to beat the comfort Vercel provides for hosting Next.js applications. Everything you need is within reach, either in the form of pre-set settings or built-in features.
Yet this convenience doesn’t come for free. Scaling Next.js projects might notice that their hosting costs start to increase, which puts them in a precarious position. They can successfully optimize Vercel costs by finding code inefficiencies and other opportunities for savings, but for some the rising costs are the push to start self host Nextjs apps.
Moving to a standalone setup gives you complete control over infrastructure and costs but also requires more investment in DevOps knowledge, modern web development techniques, and tooling.
We’ve prepared an article detailing what to consider before migrating, which providers to consider, and some challenges you might face. You can also watch our video on the topic:
Leaving Vercel
As I mentioned in the intro, for most teams, Vercel offers great value and a developer experience. It’s easy to deploy Next.js apps with and offers a wide variety of built-in features. However, as your app hits certain traffic levels, you might find dependency on Vercel burdensome.
Most companies pick self-hosting a Next.js application because of the rising hosting costs, but it’s hardly the only reason. Vendor lock, compliance needs, or a desire for greater control are just as valid and common.
That said, when it comes to speed and convenience, Vercel is hard to beat. Migrating to self-host a Next.js project should be a deliberate decision, not a knee-jerk reaction to a single pain point.
What You’ll Miss When You Leave Vercel
Switching away from Vercel means giving up a lot of built-in convenience. Out of the box, you lose:
- Automatic CI/CD pipelines and preview deployments
- Built-in CDN and edge network for global performance
- Auto-scaling infrastructure
- One-click HTTPS and SSL management
- Native support for the latest Next.js features, including server components, streaming, and app directory routing
Vercel acts as a seamless all-in-one DevOps for web applications. Without it, you’ll need to recreate that setup using custom tooling or third-party services. That means more time spent on infrastructure and maintenance.
Is Self-Hosting Nextjs Right for You?
Self-hosting may be overkill for small projects, but it’s worth considering if:
- You have a hobby project and want to learn more about hosting.
- You’re running a mid-sized app and need to reduce costs.
- You’re at an enterprise scale with a dedicated DevOps team.
For most production apps, it comes down to balancing savings against the complexity of setup maintenance.
Need to optimize your Vercel setup?
Evaluating Your Readiness
Once you decide that a self-hosted Next.js app is what you want, it’s time to see how prepared you are for a potential migration.
First, check your baseline by answering a few questions to see if you have what’s needed to run your project:
- Are you already using a cloud provider like AWS or Azure?
- Do you have in-house DevOps knowledge or the time and budget to develop it?
- Is your app high-traffic and performance-sensitive?
Once you’re sure you’re ready, you can start considering how to structure your new hosting stack.
Choosing a Hosting Path to Deploy Next.js
The first step to independence is choosing the way to self-host your Next.js app. Your choice will shape everything from cost and scalability to how much DevOps expertise you’ll need.
VPS or Dedicated Server (DigitalOcean)
Ideal for complete control. You handle everything: deployments, builds to SSL and scaling. It’s budget-friendly but time-intensive and best suited for smaller projects.
If you’re interested in the topic, I highly recommend the guide by Lee Robinson:
Cloud Providers (AWS, Azure, GCP)
It offers high scalability and flexibility. You can customize your setup using services like Lambda, S3, DynamoDB, or RDS. However, managing services, permissions, and cost control requires a learning curve and often some DevOps involvement.
Edge-first Platforms (e.g., Cloudflare)
Great for performance-driven apps. These platforms bring content closer to users by default but often require more specialized configuration and have limits on certain backend logic or frameworks.
Platform-as-a-Service Alternatives (e.g., Netlify, Amplify)
PaaS are platforms like Vercel. They abstract away most infrastructure concerns but may still lock you into certain workflows or feature sets. A smoother transition, but not as flexible or cost-efficient at scale.
Each route mixes complexity, control, and cost in different ratios. The best choice depends on different factors, mainly your team’s technical comfort, the scale of your project, and whether your priority is performance, flexibility, or ease of use.
Migration Strategies
Each migration is a unique case and requires a different approach. However, here are some common practices that can help make your transition smoother.
Move piece by piece
Trying to migrate everything in one go is a common mistake. A safer approach is to move step by step. Migrate supporting services like background jobs, cron tasks, or file storage once the core of your production environment is stable and performing well. Debugging and optimization will be easier and won’t put your entire production stack at risk.
Start with your Next.js frontend
Deploy just the UI and core pages using SST or your chosen setup. Focus on getting SSR, SSG, middleware, and API routes working first.
Keep existing services where they are
You don’t have to move your database, auth, or CMS immediately. Treat self-hosting as a gradual shift, not a full rebuild.
Introduce caching early
Tools like CloudFront (for static assets), Redis (for dynamic data), or route-based caching can help keep costs in check, especially for ISR and apps relying on APIs.
Use Docker if needed
If you’re working with a team or using custom server logic, Docker can make it easier to run your app in consistent environments, both locally and during deployment. It’s not required for every setup, but it is helpful when managing environments across VPS, staging, or Kubernetes.
AMPLIENCE – GET STARTED GUIDE
Next.js in Action: Building an Interactive Guide Demystifying CMS’s Capabilities
Read Case Study
Deploy a Next.js App with SST and OpenNext on AWS
To simplify AWS deployment, tools like SST (Infrastructure as Code) and OpenNext (build compatibility for Next.js) are helpful. They enable you to:
- Deploy SSR, SSG, middleware, and API routes.
- Connect AWS resources like DynamoDB or S3.
- Run cron jobs and auto-generate dev/prod environments.
Once configured, SST uses OpenNext to generate the correct output structure for your Next.js project. That output is then deployed across AWS services like serverless functions (Lambda@Edge), S3, and CloudFront.
Migration from Vercel to AWS with SST
I’ve prepared a simplified version of what a self-hosted migration might look like:
Set up your project with SST
Run npx create-sst@latest or sst init to bootstrap your infrastructure-as-code setup. You’ll get a basic config file where you define your cloud provider (e.g., AWS).
Configure your app
Within the SST config, define your Next.js app and its location:
new sst.aws.Nextjs("MyWeb", {
path: "./nextjs-app",This is where you configure Next.js to work with custom services like S3 and DynamoDB.
Use OpenNext under the hood
OpenNext compiles your app and splits it into separate AWS-compatible outputs: Lambda functions for SSR and API routes, static assets for S3, and CDN rules for CloudFront. You don’t need to modify OpenNext directly since SST takes care of that.
Run locally and deploy
You can test things with sst dev and then deploy to the cloud with sst deploy. SST provides a dashboard-like output in your terminal that shows all services created and URLs for access.
Add cron jobs and linked services
You can trigger functions periodically with Cron definitions:
const site = new sst.aws.Nextjs("MyWeb", {
path: "./nextjs-app",
link: [],
});
const cron = new sst.aws.Cron("MyCron", {
function: {
handler: "functions/cron.handler",
link: [site],
},
schedule: "rate(1 minute)",
});These can call internal API routes or perform data cleanup tasks.
Test core functionality
Be sure to confirm that all your functionalities are working when deployed via SST. In particular, you should check if:
- The middleware redirected requests correctly.
- SSG pages respected revalidate intervals.
- SSR pages pulled fresh CMS content.
- API routes handle POST requests and database operations.
Common Challenges for Standalone Hosting
Self-hosting gives you more flexibility, but it also means you’re responsible for everything Vercel used to handle for you. That learning curve can be steep, especially at the beginning.
You can expect friction in a few areas:
Setup and Configuration
Tools like SST and OpenNext simplify the config process, but they still require a working understanding of cloud infrastructure. Small missteps, like misconfigured paths, missing environment variables, or incorrect IAM permissions, can break your app or derail the deployment process.
Debugging and Error Handling
Unlike Vercel, which gives clear feedback in a unified dashboard, cloud platforms often scatter logs across multiple services (e.g., CloudWatch, Lambda, S3). Errors can be vague or buried in nested stack traces, which slows down root cause analysis.
Documentation and Support
Vercel’s documentation is tightly focused on one framework. AWS documentation, meanwhile, is broad but fragmented. You’ll spend more time piecing together solutions across blog posts, GitHub issues, and Stack Overflow.
Cost Management
Without guardrails, it’s easy to misconfigure services in ways that spike your bill. Common problems include very long and repetitive cron jobs, functions that don’t terminate properly, or unintentionally high traffic to endpoints that aren’t cached.
If you’re unsure what a command or config does, pause. Double-check the docs, test locally first, and don’t be afraid to ask for help or call in a consultant. It’s better to lose an hour up front than rack up unexpected costs or burn days debugging an invisible misstep.
Conclusion
Self-hosting offers flexibility and cost control, but you also take on the overhead of infrastructure, deployment, and debugging.
For some teams, that’s a worthwhile move, particularly if you’re scaling quickly, hitting platform limitations, or want to break free from vendor lock-in. For others, a better option might be squeezing more value out of Vercel through code optimizations and smarter usage of their features.
Either way, the important thing is to be intentional. Don’t jump ship because of one frustrating bill or performance hiccup. Test assumptions. Plan your migration. Move gradually.
Ready to start self-hosting your Next.js app?
