> ## Content Index > Fetch the complete content index at: https://blogs.remobjects.com/llms.txt > Use this file to discover other available public pages before exploring further. # Elements Server Pages 2.0 - URL: https://blogs.remobjects.com/2026/10/08/elements-server-pages-2-0/ - Published: 2026-10-08T12:46:46.000Z - Updated: 2026-10-08T12:46:46.000Z - Author: marc hoffman Over four years ago, we first [introduced ESP](https://blogs.remobjects.com/2022/01/11/esp/), our take on keeping classic ASP.NET alive in a world of .NET Core, and on native. In part because our websitebis built in it and – frankly – we like to keep it that way. Today, we're announcing a major milestone in the evolution of ESP, with improved compatibility with Classic and many new features, both for building and deploying ESP apps. ## Monolithic Server vs. Live Mode ESP can run in two modes now, similar to classic ASP.NET in IIS: - **Monolithic**: You can build your site into a standalone server executable you can deploy like you would any other app; when run, it will open a HTTP server on the port of your choosing, and serve your entire site. Nice and self-contained. - **Live Mode**: You can point EBuild at your website project or folder, and it will build its current state and start serving it, *and* it will monitor for file changes. If files changed on disk, it will rebuild the changes and make them available seamlessly, withour restart – just like a Website project in IIS. A single project can run in both modes, e.g., use Live mode locally as you develop, and then build a self-contained executable to deploy. ## Live Mode in Fire, Water, and Earth Fire & its siblings have gotten dedicated support for live mode. You can enable **UseLiveMode** in project settings or `Web.config`, and Fire will enable a new "**Project|ESP**" submenu and corresponding toolbar button. Here you can start and stop a live server for your project to test your site. EBuild will launch into Live Mode, build your project, and start serving it. Fire will stay connected to it, and surface any errors that happen as you develop via its standard UI. As you change your code, the site updated automatically. ## Deployment ESP offers many options for deployment. **Monolithic** mode is, of course, simple. You build your app, and it contains your full site – just ship and run it wherever you want. **Live Mode** has many options to control how you deploy, all handled by running `EBuild` with the `--server-web-project` switch. The simplest is "full build". EBuild will build your site and serve it; if the code changes, EBuild will rebuild it and (on success only) switch over to the new version You can also opt to incremental build by passing `--incremental`. EBuild will only build the basics (`App_Code`, etc) and start your server. Additional pages, master pages, controls, and the like will be built when first requested. This starts faster and updates faster as code changes. But it can also hide errors – you won't know that some page fails to compile until you visit it. As you update code, EBuild will smartly invalidate old binaries and recompile as needed. The nice thing here is, if a page fails to build after an update, ESP will keep serving the last good one (by default), instead of showing your visitors an error. Of course, it will still report the error. And you can opt out of this – good for when running your page in debug mode while working. ### Advanced Options You can decide whether EBuild rebuilds as soon as it sees changes (the default), or only when manually triggered (good for production, it allows you to deploy a consistent set of changes at once). ESP can serve informational page under the `/__esp` sub-path, including - `/__esp/status` \- the current status of the site - `/__esp/update` \- to optionally trigger an upodate/rebuild as well as more detailed error diagnostics for Exceptions and compile errors (if so configured). ## HTTPS ESP standard server purposely does not handle TLS and HTTPS itself. Configuring certificates is a complex subject, and everyone has their own way of doing things. Our way of deploying ESP servers (or any HTTP server, really) is to host them behind a local [nginx](https://nginx.org/?ref=blogs.remobjects.com), [Kamal](https://kamal-deploy.org/?ref=blogs.remobjects.com), or similar hosting scaffolding. ## Templates It even comes with new templates to get you started quickly: ![](https://blogs.remobjects.com/content/images/2026/10/image-3.png) ## Syntax Extensions Now that we've broken free of the "real" ASP.NET engine, it also means we are able to improve on its design and add new features. For example, this week's build will introduce a new `<%~expression%>` syntax that – similar to `<%=expression%>` will print an inline value – but passes it through a (customizable and overridable) localization engine. That streamlines localizing your website a lot. ## Native Web Assuming your own website code is cross-platform and does not depend on .NET APIs (aside from those replicated by ESP), you are not limited to building your website for .NET. You can also use it to create a fully native Windows, macOS, or even Fuchsia binary that can serve your ESP website! That can be useful, for e.g., providing a small web-based config panel on an embedded device. Java is supported as a platform, as well. ![](https://blogs.remobjects.com/content/images/2026/09/aspnet-like-fire-water-earth-blog-banner-1.jpeg) ## remobjects.com Our website, [remobjects.com](https://www.remobjects.com/?ref=blogs.remobjects.com), has been running on ESP for the last month now, by the way, with .NET Core 10 on Ubuntu Linux. This past weekend, we also switched the database over from an old Microsoft SQL Server to PostgreSQL. Thanx to [Data Abstract](https://www.remobjects.com/da?ref=blogs.remobjects.com), with *zero* code changes needed. ## Try ESP yourself now Try ESP 2.0 now, in Elements build .3133 or later. ![](https://blogs.remobjects.com/content/images/2026/10/image-4.png)