Nesly Serverless Platform
Push your code and go live in Istanbul without setting up a server
Nesly detects your project, builds it and serves it at its own address over HTTPS, with databases, domains and preview environments a few commands away. Your apps and data run in Istanbul, on infrastructure Nesnet operates.
Why now
- On a three-person team, one day a week goes to server updates, certificate renewals and backup checks. On Nesly, builds, addresses, HTTPS and nightly backups are already handled, and that day goes back to the product.
- Your users' data has to stay in Türkiye, yet the push-to-deploy experience you are used to lives on platforms abroad. Nesly brings the same workflow to infrastructure in Istanbul.
- Your .NET application depends on SQL Server and you need one platform to host both. Nesly offers managed SQL Server alongside PostgreSQL.
- You want to see every change running before it goes live, but the shared test server is always busy with someone else's work. On Nesly every pull request gets a preview at its own address.
- You want an AI agent to handle deployments, but it gets lost in piles of logs. Nesly's MCP server and JSON-output CLI were designed for an agent to read directly.
What changes
| Today | With Nesnet |
|---|---|
| Servers are set up, operating systems patched and certificates renewed by hand. | You push, and the build, address and HTTPS certificate arrive from the platform. |
| Changes queue up for a turn on a shared test server. | Every pull request gets a preview at its own address, posted as a comment on the PR. |
| Backing out a bad release means rebuilding and waiting. | One command switches traffic to the previous deployment, with nothing rebuilt. |
| The database is set up separately and backed up when someone remembers. | The database attaches with one command and is copied automatically every night. |
| You pay every month for a server that sits idle. | An app with no traffic is paused, and you never pay for an idle server. |
From today to live: how it works
- 1
Account and project
Open your account and project on nesly.net, either in the console or with the CLI installed through a package manager. The project gets its own address the moment it is created.
- 2
Connecting your code
Connect your GitHub repository to a branch, or run nesly deploy in the project directory; the language and framework are detected from your files.
- 3
First release and previews
A push to the connected branch goes to production, and every pull request gets its own preview address. If something breaks, one command switches traffic back to the previous deployment.
- 4
Add-ons and domain
Attach a database or bucket the moment you need one, verify your domain with its DNS records, and the HTTPS certificate arrives on its own.
- 5
Team
Invite teammates with the right role; viewers never see secret values.
What you get
Deploy on push, preview on pull request
Every push to the GitHub branch you choose goes to production. Each pull request gets a preview at its own address, the address is posted as a comment on the PR and the preview is removed automatically when the PR closes.
Previews only your team can see
Preview addresses can be password-protected, so you try an unreleased feature as a team without showing it to customers or search engines. A separate bypass token is issued for your automated tests.
Builds that recognise your project
Node.js, Python, Go, .NET, Ruby, PHP and Java projects are detected from your files, with the package manager taken from your lockfile and the Node version from engines.node or .nvmrc. When you need settings, nesly.toml defines the root directory, build command and output directory, and monorepos are supported.
Your front end live as a static site
Vite, Astro, SvelteKit, Angular or exported Next.js projects are built and served as static sites. If there is a Dockerfile at the root, Nesly uses it, so a custom runtime is always an option.
Databases and storage in one command
PostgreSQL, MySQL, SQL Server, MongoDB, Redis-compatible Valkey, S3-compatible buckets and OpenID Connect clients attach as add-ons. Connection details arrive as environment variables such as DATABASE_URL, and add-ons have no public address; your app reaches them over the private network.
Instant rollback
When a release misbehaves, traffic switches back to the previous deployment without rebuilding anything. Rolling back takes one command or one click in the console and never waits in a build queue, so customers do not stare at the error for minutes.
Your own domain with automatic HTTPS
You verify your domain with a CNAME and a TXT record, or an A record for the apex. The certificate is issued and renewed automatically, and the project's default address keeps working alongside it.
Buy your domain here too
Search for, buy and delegate a domain for a new project from the CLI or through your agent. Domain, DNS record and certificate sit in one place, so you never bounce between three providers' dashboards.
Automatic nightly backups
Your database is copied automatically every night, you can take a manual backup whenever you like, and a safety copy is taken right before every restore. Backups can be downloaded as a PostgreSQL custom-format archive or a SQL Server .bak file.
Deleted data does not vanish at once
If you delete a database add-on by mistake, the data is not dropped on the spot; access is cut first and the data is removed only at the end of a recovery window. Within that window you can ask for it to be brought back.
Role-based team access
Team members join as owner, admin, member or viewer, and roles are enforced on the server for every API call. A viewer can see the name of an environment variable but never its value.
Scheduled jobs and one-off commands
You can define cron jobs and run one-off commands such as migrations with nesly run. Logs are readable in the console, can be shipped out through a log drain, and events are announced by webhook.
Minimal GitHub permissions
Nesly asks GitHub only to read contents and metadata and to write commit statuses and PR comments. Build tokens expire within an hour, no personal token is stored, and pull requests from forks are not built so your environment variables are never handed to outside code.
Let your agent tell you what broke
Your agent deploys over a local or remote MCP server. When a build fails, nesly diagnose returns the cause, the log lines that prove it and the fix command, and the agent applies the fix and redeploys.
Apps that sleep when idle
An app that receives no traffic is paused, and the first request wakes it within a few seconds, so you never pay for an idle server. For apps that must never keep a visitor waiting, there is an always-on option.
Every pushed image is scanned
The built image goes to a private registry only the platform can reach and is scanned for vulnerabilities the moment it lands. Secrets in environment variables are encrypted, with the key held in a separate vault rather than next to the data.
Valkey with guard rails between projects
On Valkey each project has to use its own prefixed keys, and dangerous commands such as FLUSHALL are refused. When the server fills up, another project's data is never evicted; new writes return an error instead.
Your site stays up when your allowance runs out
You get an email when usage reaches 80 percent and again at 100 percent of your plan allowance. When the allowance runs out, your running site stays live and only a new build, project or domain has to wait until the allowance renews.
Why Nesnet
Nesnet's own product
Nesly is built and operated by Nesnet, and the contracting party is NESNET INTERNET HIZMETLERI TIC A.S. The platform runs on a Kubernetes cluster in the Nesnet cloud, and the nesly.net website itself is built and served on Nesly.
Every container in its own sandbox
Each project gets its own Kubernetes namespace, and every application container runs inside a sandbox that isolates it at kernel level. Network policy lets a workload reach only DNS and the internet over 80/443, with no route to private address space or other customers.
Data in Istanbul, in writing
Your apps and data sit in Istanbul on infrastructure Nesnet operates. A data processing addendum (DPA) is part of the contract, and in the event of a personal data breach the customer is notified without delay at the registered email address.
.NET and SQL Server as first-class citizens
Nesly detects .NET projects on its own and offers managed SQL Server next to PostgreSQL. SQL Server backups download as .bak files that restore anywhere with the standard tools.
Designed for AI agents
Nesly provides local (stdio) and remote (OAuth) MCP servers plus a plugin for coding agents. Every CLI command prints a single JSON object with --json and exits with fixed codes, so your agent reads the output without guessing.
Answered by real people
Support comes mainly by email, and your questions are answered by real people on the Nesly team, not by an automated reply system.
Example scenarios
An internal .NET and SQL Server application
Situation
A company's internal .NET application depends on SQL Server and runs today on a server in the office. Patching and backing up that server rests with a single person.
Outcome
On Nesly the application builds automatically as .NET, a SQL Server add-on is attached and the connection arrives through ConnectionStrings__Default. The database is copied every night, and a backup can be downloaded as a .bak file whenever it is needed.
A small product team working through pull requests
Situation
A three-person product team wants to see every change running before it goes live. Their shared test server is always busy with someone else's change.
Outcome
Each pull request gets a preview at its own address, posted on the PR and protected by a password. Changes merged into the main branch go to production, and if something breaks, traffic switches back to the previous deployment.
A developer who lets an AI agent deploy
Situation
A developer runs code and deployments through an AI coding agent. When a build fails, the agent loses time digging through piles of logs for the cause.
Outcome
The agent connects to Nesly's MCP server and handles the deployment itself. When a build fails, nesly diagnose gives the cause and the fix command, and the agent applies the fix and redeploys.
An agency launches a campaign site in an afternoon
Situation
A digital agency is building a two-week campaign site for a client that has to be live tomorrow morning. It does not want to wait on separate people for a server, a domain and a certificate.
Outcome
The agency connects its Astro project to GitHub, buys and verifies the domain from the CLI, and the certificate arrives on its own. When the campaign ends the project goes to sleep, and nobody pays for an idle server.
A start-up brings its data home to Türkiye
Situation
A start-up's web app and database run on a platform abroad. Its new enterprise customer wants the data in Türkiye and a written data processing addendum.
Outcome
The app connects to Nesly from the same repository, a PostgreSQL add-on is opened and the data is imported from a standard archive. App and data run in Istanbul, and the data processing addendum becomes part of the contract.
Who does what
| Nesnet | You |
|---|---|
| Runs the build, publishing, addressing and HTTPS certificate infrastructure. | You write your application code and push it to GitHub or send it with nesly deploy. |
| Separates projects by namespace, containers by sandbox and the network by policy. | You decide on environment variables, add-ons and, if needed, nesly.toml settings. |
| Copies databases every night and takes a safety copy before every restore. | You add the DNS records for your domain. |
| Scans every pushed image for vulnerabilities and encrypts secrets with keys held in a separate vault. | You decide which role each team member gets. |
| Warns you by email before your plan allowance runs out and never stops a running site. | You decide whether an app stays always on or sleeps when idle. |
Who it is for
Teams shipping to the web
Teams shipping websites, web apps or APIs, from a landing page to a product with a database behind it. They go live without touching servers, operating systems or certificates.
Data that must stay in Türkiye
Teams whose users and data need to be in Türkiye. Apps and data stay in Istanbul on Nesnet's infrastructure, and a data processing addendum is part of the contract.
.NET and SQL Server teams
Teams working with .NET and SQL Server. The stack runs as it is, and connection details arrive in the variable .NET expects.
Agent-driven developers
Developers who run deployments through an AI agent. The agent deploys over MCP, reads why a build failed and gets the command that fixes it.
Popular frameworks
Teams using Laravel, Rails, FastAPI, Flask, Express, ASP.NET or Go. Each of these has a ready-made deployment guide.
May not be the right fit
Applications that need outbound ports other than 80 and 443, or that send email straight out on port 25; Nesly workloads can reach only DNS and the internet over 80/443. Virtual Servers or Managed Kubernetes fit better: you manage network and firewall rules yourself from the portal.
Teams that want to install their own operators and have full admin access to a cluster. Managed Kubernetes fits better, since it comes with an admin kubeconfig.
Projects whose builds run longer than 15 minutes or whose uploaded source exceeds 256 MiB, which are Nesly's platform limits. The CI/CD Pipeline with Managed Kubernetes fits better, with builds running on a runner dedicated to your project.
Under the hood
Nesly is a platform Nesnet wrote on top of a Kubernetes cluster in the Nesnet cloud. When your code arrives it identifies the language and framework from your files: Node.js, Python, Go, .NET, Ruby, PHP and Java build automatically, a Dockerfile at the root takes precedence, and front-end projects such as Vite, Astro or SvelteKit come out as static sites. The built image is pushed to a private registry only the platform can reach and is scanned for vulnerabilities the moment it lands. Each project runs in its own namespace, and every container runs in a sandbox that puts a separate isolation layer between it and the kernel, while a network-policy layer keeps projects apart. Secrets in environment variables are encrypted with AES-256-GCM, and the key lives in a separate key vault rather than next to the data. Account passwords are never written to the platform database; they are held in a separate identity service. HTTPS certificates for custom domains are issued automatically and renewed before they expire.
Building blocks
- Kubernetes (Nesnet cloud)
- the cluster the platform runs on
- Container sandbox
- isolates every application container from the kernel with a separate layer
- Network-policy layer
- project network isolation and egress rules
- Key vault
- holds the keys that encrypt secrets, apart from the data
- Identity service
- accounts, passwords and OIDC clients for applications
- Scanning on push
- every image written to the private registry is checked for vulnerabilities
- Automatic certificate management
- HTTPS for custom domains, renewed before expiry
How it compares
| Option | When it is the right choice |
|---|---|
| Managed Kubernetes with the CI/CD Pipeline | The right choice if you want your own cluster, separate test and production environments and a setup where only a release team can ship. You get admin access to the cluster and can install your own operators. |
| Virtual Servers | A better fit if you want to manage the operating system yourself, open whatever ports you need or run long jobs on an always-on server. Updates, certificates and backups then stay with you. |
Technical specifications
| Auto-detected runtimes | Node.js, Python, Go, .NET, Ruby, PHP, Java; a root Dockerfile takes precedence |
|---|---|
| Front-end frameworks built as static sites | Vite, Create React App, Astro, SvelteKit, Next.js (export), Angular, Gatsby, Docusaurus, VitePress, Eleventy |
| Configuration | nesly.toml (root, install, build command, output directory); monorepo support |
| Listening port | The PORT environment variable, bound to 0.0.0.0 |
| Platform limits | Source upload 256 MiB and 100,000 files; build time 15 minutes |
| Workload isolation | A namespace per project; every container in a kernel-isolated sandbox |
|---|---|
| Network | Egress only to DNS and 80/443; outbound port 25 closed |
| Secrets | AES-256-GCM; key held in a separate vault |
| Image scanning | Every pushed image, on arrival; private registry |
| Add-ons | PostgreSQL, MySQL, SQL Server, MongoDB, Valkey, S3-compatible bucket, OIDC client |
|---|---|
| Copies | Nightly automatic, manual backups, safety copy before restore |
| Backup format | PostgreSQL custom-format archive; SQL Server .bak |
| Limits | No point-in-time recovery (PITR); 256 MB archive limit for SQL Server backup and restore |
| CLI output | A single JSON object with --json; fixed exit codes 0–5 |
|---|---|
| Data location | Istanbul, Türkiye; infrastructure operated by Nesnet; DPA part of the contract |
If something breaks
If a live release misbehaves
One command or one click in the console switches traffic back to the previous deployment. Nothing is rebuilt to do it.
If the wrong backup is restored
The safety copy taken just before the restore stays in your backup list. Restoring that copy takes you back to where you were.
If a database add-on is deleted by mistake
The data is not dropped on the spot; access is cut first and the data is deleted only at the end of a recovery window. You can ask for it to be brought back within that window.
If a build fails
nesly diagnose tells you the cause, the log lines that prove it and the command that fixes it. Your running release stays live in the meantime.
If you run out of plan allowance
Your running site does not stop; only new work such as a fresh build, project or domain is refused. You get an email warning when usage reaches 80 percent and again at 100 percent.
Frequently asked questions
Pricing and first steps
Pricing
You start on Nesly with a free plan that asks for no card, then move to a monthly or yearly subscription as you grow, and you never pay for a server sitting idle. Invoices are issued with VAT included as e-invoices, and plan details are published on nesly.net.
What the price depends on
- The subscription plan and billing period you choose (monthly or yearly)
- Keeping an app always on instead of letting it sleep when idle
- Domains you buy through Nesly
How to get started
- 1.Go to nesly.net and open your account.
- 2.Connect your GitHub repository or run nesly deploy.
- 3.Your first push goes live at its own address, over HTTPS.
Go live in Istanbul without setting up a server
Open your account and connect your repository, and your first push goes live at its own address over HTTPS. Your code runs in an isolated sandbox and your data stays in Istanbul.