# Introduction
Source: https://magicserver.arsh.sh/docs
Easy, Automatic HTTPS for Node.js
## What is MagicServer?
MagicServer adds automatic HTTPS to your Node.js apps.
It automates the issuance, usage, and renewal of TLS certificates for your domains, so you can deploy secure sites without touching cron jobs, cryptography, or reverse proxies.
All you need for HTTPS without the pain.
Automatic certificate renewals to keep your applications humming.
Batteries included, and sensible defaults.
No reverse proxy needed. Build applications, not infrastructure.
## Quick start
Get up and running within minutes with a 4-step guide.
# Google
Source: https://magicserver.arsh.sh/docs/authorities/google
Automatic HTTPS certificates for Node.js applications using Google Cloud's Public CA
Support for Google Cloud's Public CA is consideration.
Please check back later :)
# Let's Encrypt
Source: https://magicserver.arsh.sh/docs/authorities/letsencrypt
Automatic HTTPS certificates for Node.js applications using Let's Encrypt
Let's Encrypt is used by MagicServer by default, so you don't have to do anything to enable it.
However, if you wish it to be explicit about which certificate authority is being used, you may manually specify when calling `createMagicServer`.
```js theme={null}
import { letsencrypt } from "@magicserver/magicserver/authorities"
const server = createMagicServer("your-domain.com", app, {
authority: letsencrypt
})
```
# How It Works
Source: https://magicserver.arsh.sh/docs/how-it-works
It's not a sleight of hand! Learn the magic behind MagicServer.
MagicServer uses [Let's Encrypt](https://letsencrypt.org/).
Let's Encrypt is a free service that provides TLS certificates, which are also called certificate authorities (CAs).
These certificates are given if an application is able to prove that it controls the domain for which the certificate is requested.
As an ACME client, MagicServer can request certificates from any CA that offers an ACME server, not just the ones provided by Let's Encrypt.
MagicServer still uses Let's Encrypt by default as their service doesn't require signing up for an account, and it is operated for public benefit by ISRG, a non-profit organization.
## ACME overview
The way in which MagicServer communicates with the CA is called the ACME protocol. At a high level, this involves the following steps:
MagicServer orders a certificate from the CA for the domain.
The CA responds with a list of challenges MagicServer can complete to prove that it controls the domain.
MagicServer selects and completes one of the challenges, and indicates to the CA that the challenge is ready to be verified.
The CA validates the challenge, and if successful, allows downloading a new certificate for the requested domain.
## Challenges
The ACME server run by the CA asks MagicServer to prove that it controls the domain by completing one of a few types of challenges.
#### HTTP-01
MagicServer always attempts the this challenge.
This challenge is completed by responding to an HTTP request at `/.well-known/acme-challenge/*` with a specific value.
To do this, MagicServer temporarily serves an HTTP server on port 80.
#### TLS-ALPN-01
Advanced challenge that may be used when HTTP-01 is not viable.
Not used by MagicServer.
#### DNS-01
This challenge is completed by creating a TXT record with a specific value under the requested domain name.
Not used by MagicServer.
## Renewals
Certificates are renewed automatically before expiration.
To determine the ideal time to renew, MagicServer checks the duration of certificate validity, and waits until it's age is at least 2/3 of the validity duration.
For example, if the CA provided a 90 day certificate, MagicServer will ask for a new one 60 days after its issuance.
Interested in what I do? I am looking for full-time oppurtunities!
Hi, I am Arsh.
I am a serial builder addicted to difficult and impactful challenges.
You can review my work on my [website](https://arsh.sh) and on my GitHub [profile](https://github.com/lilnasy).
Let's [schedule an introduction](https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ3ChoWFCFbrieMOvlK_JKikkb5Lky0DQ20HBwWA2e9WfEIY5K1NKk4Iul2y3pTvwHwrZ2Oy-6ba).
# Astro
Source: https://magicserver.arsh.sh/docs/integrations/astro
How to add automatic HTTPS to your Astro SSR application with MagicServer
This page has not been written yet. Please check back later :)
# Express
Source: https://magicserver.arsh.sh/docs/integrations/express
How to add automatic HTTPS to your Express application with MagicServer
This page has not been written yet. Please check back later :)
# I want to use something else
Source: https://magicserver.arsh.sh/docs/integrations/more
Request a new integration with MagicServer
If you would like to see MagicServer integrated with another framework or library, please open an issue on GitHub.
# Node.js
Source: https://magicserver.arsh.sh/docs/integrations/nodejs
How to add automatic HTTPS to any Node.js application with MagicServer
**Prerequisites**:
* A recent version of Node.js (22 or higher)
* A package manager like npm, pnpm or yarn
Before we can start with any code, we need to ensure that the application's domain is pointing to the server.
To do this, go to your cloud provider's dashboard and find the IP address of the machine that will run your application.
Then, from your DNS provider's dashboard, create an "A" record with the value set to the IP address of the server.
```bash theme={null}
npm install @magicserver/magicserver
```
```bash theme={null}
pnpm install @magicserver/magicserver
```
```bash theme={null}
bun install @magicserver/magicserver
```
```bash theme={null}
yarn install @magicserver/magicserver
```
```js server.js theme={null}
import { createServer } from "node:http" // [!code --]
import { createMagicServer } from "@magicserver/magicserver" // [!code ++]
function app(req, res) {
res.end("Hello, World!")
}
const server = createServer(app); // [!code --]
const server = createMagicServer("your-domain.com", app); // [!code ++]
server.listen(80) // [!code --]
```
Notice that we also removed the `server.listen()` call.
We do this because MagicServer will automatically listen on port 443, which is the port for HTTPS.
Now whenever your application is started, it will be automatically served over HTTPS and stay up to date with certificates without needing any intervention.
```bash theme={null}
node server.js
```
It’s not a sleight of hand! Learn the magic behind MagicServer.
# Nuxt
Source: https://magicserver.arsh.sh/docs/integrations/nuxt
How to add automatic HTTPS to your Nuxt application with MagicServer
This page has not been written yet. Please check back later :)
# Remix
Source: https://magicserver.arsh.sh/docs/integrations/remix
How to add automatic HTTPS to your Remix application with MagicServer
This page has not been written yet. Please check back later :)
# MagicServer vs Caddy
Source: https://magicserver.arsh.sh/docs/magicserver-vs-caddy
We love [Caddy](https://caddyserver.com/)!
Like MagicServer, Caddy offers automatic HTTPS, and was the inspiration for the project!
If you are already using Caddy, **you probably don't need MagicServer**.
As a library, however, MagicServer offers important advantages.
## Simplicity
While it requires minimal configuration, Caddy needs to be installed separately.
It's an additional piece of software to wrangle, and if you are working within a team, to document.
Making use of MagicServer requires no changes to how you build and deploy.
It runs within the single process of your application; one less moving part to worry about.
## Performance
Routing requests through a reverse proxy introduces a performance overhead.
MagicServer handles TLS termination directly in your process.
Zero network hops, zero proxy overhead.
Your application serves HTTPS requests directly, achieving lower latency and higher throughput.
## Advanced Use Cases
Since Caddy runs as an independent process, it can route requests to multiple applications, all while serving the same domain with HTTPS!
This allows you to run a single site with parts provided by different applications, which may be written in different programming languages,
a feature not possible with MagicServer.
Additionally, Caddy is a pioneer in all things ACME.
It is feature packed for all sorts of niche requirements, like wildcard certificates and ARI extension.
Though actively developed, MagicServer focuses on the most common use cases.
As your needs grow, you may want to consider Caddy.
## Conclusion
We believe Caddy has its place, but it's not challenging MagicServer's.
MagicServer targets the most common scenario: **one application, one domain, effortless HTTPS**.
If that describes your use case, MagicServer delivers automatic HTTPS with less complexity, better performance, and zero operational overhead.
Choose simplicity when you can. Upgrade to complexity when you must.
# Why MagicServer?
Source: https://magicserver.arsh.sh/docs/why-magicserver
HTTPS is table stakes in 2025
The era where HTTPS was a nice-to-have is long gone.
Browsers are no longer subtle about whether a site is HTTPS or not.
Your users will know there's something wrong with your service before they know its name.
## Development time is an expensive resource.
It is valuable to have the skills to wrangle cron jobs, shell scripts, and system services required by traditional certificate automation.
It is more valuable to not have to do it.
MagicServer simplifies HTTPS setup so you can focus on the product.
## The price of convenience doesn't need to be high.
Serverless platforms reduce development time in exchange for a multiplier on your cloud bill.
MagicServer brings the same convenience to on-prem and self-hosting for free.