n nesly
Menu
TR Sign in

Changelog

What shipped, newest first. Anchored to the public releases where one exists.

Hugo and MkDocs starters

  • nesly new hugo-site and nesly new mkdocs-docs scaffold a working static site or docs site — the Hugo starter ships its own layouts, so there is no theme submodule to lose on deploy.

Docs in markdown, for agents

  • Every docs page now has a markdown twin: replace the trailing slash with .md (docs/builds/ → docs/builds.md). Generated from the rendered page at build time, so it can never drift from what humans read.

A Claude Code plugin

  • Install nesly as a Claude Code plugin — /plugin marketplace add neslyhq/claude-plugin, then /plugin install nesly@nesly — and Claude gets the MCP tools plus a skill that knows the deploy workflow: the $PORT contract, build detection, and diagnose-first when something fails.
  • The manual path still works everywhere else: any MCP client can run `nesly mcp` on stdio.

Hugo, Jekyll and MkDocs deploy like everything else

  • The three big non-Node static site generators are now detected and built with their own toolchains — hugo --minify, bundle exec jekyll build (or stock Jekyll without a Gemfile), mkdocs build — and served as static files.
  • Deploy guides with the real pitfalls (submodule themes, macOS Gemfile.lock, requirements.txt for your MkDocs theme): /deploy/hugo/, /deploy/jekyll/, /deploy/mkdocs/.

SQL Server restore, into the platform

  • `nesly backup restore` now works for mssql databases — the same contract as postgres: a safety copy of the current data is taken first, then the archive replaces the database, and the tenancy fence is re-established.
  • Downloading the .bak and restoring it elsewhere still works; nothing was taken away to add this.

A doomed deploy is refused in seconds, not minutes

  • A Python project with no start command used to build, start, exit, and time out five minutes later. It is now refused before the build, with the exact nesly.toml lines that fix it.
  • `nesly build show` prints the same warning before you deploy anything.
  • `nesly diagnose` now catches a nesly.toml key the platform ignored (a build setting outside [build], or a typo) and quotes the build-log warning as evidence.

Deploy guides and honest comparisons

  • Nine framework guides (/deploy/nextjs/ … /deploy/go/) that say exactly how detection sees your project — sourced from the detection code, not marketing.
  • Five comparison pages (/vs/vercel/ … /vs/heroku/) that list what the other platform has that we do not, in writing, before you migrate.

Templates: two commands to a live URL

  • `nesly new` lists deployable starters — Astro static, Node + PostgreSQL, Python FastAPI, .NET + SQL Server — and `nesly new <template>` copies one into a fresh directory with the commands to go live.
  • Every template is a complete, readable project in the public neslyhq/templates repository, deployed live before it is listed.
  • The /templates/ gallery shows the same list the CLI reads — one manifest, no drift.

SQL Server for .NET projects

  • `nesly addon add mssql` attaches a managed SQL Server database (Express edition, 10GB per database) with the same tenancy fence as postgres: your own login, your own database, other projects' names not even visible.
  • Next to DATABASE_URL it injects `ConnectionStrings__Default` — an ASP.NET app reads it with `GetConnectionString("Default")`, zero configuration code.
  • Nightly backups produce a standard .bak you can download and RESTORE DATABASE anywhere. Restoring back into the platform is not there yet, and the CLI says so instead of pretending.

Built to be operated by AI agents

  • `nesly mcp` serves the whole platform as MCP tools from the CLI binary you already have — deploy, logs, env, domains, addons, rollback. `claude mcp add nesly -- nesly mcp`.
  • `nesly diagnose` (and the diagnose_deployment tool) explains a failed deployment: the exact log lines as evidence, env vars your app reads but the project does not define, and the command that fixes each finding.
  • A failed `nesly deploy` now points at `nesly diagnose` instead of leaving you with a raw log.
  • AI assistants fetching nesly.net receive the agent briefing (llms.txt) directly; the new /docs/agents/ page documents the MCP setup and the --json contract.

Trust pages: security, status and this changelog

  • A /security page that lists only what is actually built — isolation, image scanning, encryption at rest, network fencing — and says openly what is not there yet.
  • A public status page tracks the site, console and API from outside our infrastructure.
  • Vulnerability reports now have a standard address: /.well-known/security.txt (RFC 9116).
  • Contact page: pre-addressed mail links for support, billing and security, and a line for enterprise / bank-transfer questions.

Plan allowances, notifications, and your data being yours

  • Plans now state exactly what they allow (projects, build minutes, traffic, team seats, backups) — and the platform enforces the same numbers it shows. `nesly limits` prints yours.
  • When an allowance runs out, your site keeps serving; only new builds wait for the next month.
  • E-mail notifications: failed production deploys, 80% and 100% usage warnings, backup failures, billing events. Per-category switches in the console; billing mail is always on.
  • Export everything the platform holds about your account as one archive (`nesly account export`), and close the account yourself — guarded by typing the account's e-mail address.

Backups, one-off commands, and root domains

  • Managed databases are backed up nightly; list and restore from the console or `nesly addon backup`.
  • `nesly run` executes a one-off command (migrations, seeds) with the same image and environment as the running app.
  • Custom domains now work at the apex (example.com, not just www) with per-domain certificates.
  • Deleting a database no longer drops it instantly — it is fenced off and kept as a tombstone first.

GitHub App: push to deploy, PR previews

  • Connect a repository through the nesly GitHub App — private repositories included, no deploy keys to manage.
  • Every push to the production branch builds and deploys; every pull request gets its own preview URL and a commit status.

Build settings, machine credentials, and a platform that explains itself

v0.4.0
  • Framework detection with overrides: build and start commands, root directory, nesly.toml committed next to your code.
  • Access tokens for CI (`nesly token`): deploy from a pipeline without a browser session; revocation is immediate.
  • Team roles are enforced on the server — owner, admin, member, and a read-only viewer.
  • Environment variable values are encrypted at rest; keys live in a secrets manager.
  • Visitors of a paused or broken app see a real status page instead of a blank error, with correct Retry-After.
  • Sign-in endpoints are rate-limited. Build logs survive platform restarts.
  • The whole control plane installs from one Helm chart.

The public edge

v0.3.0
  • nesly.net, console.nesly.net and api.nesly.net are live behind the platform's own edge with TLS termination.
  • The CLI talks to the public API by default — no VPN, no tunnel.

The product is called nesly

v0.2.0
  • One brand everywhere: nesly / nesly.net, module and API namespaces included.

Signed macOS binaries

v0.1.1
  • The darwin CLI builds are signed and notarized; `brew install neslyhq/tap/nesly`.

First release

v0.1.0
  • Deploy static sites and container applications from the CLI; every project gets a live URL with TLS.
  • Managed PostgreSQL per project, with a real tenancy fence.
  • Applications run sandboxed (gVisor) with resource bounds; every image is scanned on push.
  • Sign up with e-mail or social login; subscriptions with a 30-day trial.
  • Usage metering with daily charts in the console.