Web Server Configuration Features

Fenix is capable of hosting multiple web servers simultaneously. Each server has a number of basic configuration options. Several features may also be controlled globally through preferences.

Server Name

Each server has an editable descriptive name/title to quickly identify it.


All web servers require ports. Public web servers typically run on port 80. This is a protected port on desktops, and it's impossible to run more than one server on any given port at the same time. Fenix automatically assigns an available port (by default), which can be modified at whim. If you prefer not to use ports, domain names are also available in commercial editions.

Domain Names

-- PRO Feature --

Fenix PRO has a local DNS server, capable of supporting domain names like mydomain.com.

Web Root

Web servers must have a root directory containing the files to serve. The core (free) version of Fenix supports a single web root directory, which is suitable for serving many web projects. Fenix PRO supports multiple web root directories per server.

Multiple web roots are useful for sharing common or repeatedly used resources. For example, a company may use a common set of icons and CSS styles across all projects. These can be stored in a single directory and used as a root on any web server.

Any number of web roots can be defined in any order. The order in which they are listed is important. When a request is made to the server, Fenix will scan the directory in search of the file and reply with the first match it finds.

Default File Names

When a request is made to a server that does not specify a particular file, default file names can be used. This is a standard feature of all major web servers. By default, Fenix uses the industry standard list of index.html, index.htm, default.html, default.htm. This list can be set globally for all servers, or for each individual server.

Request Logging

By default, Fenix logs requests in realtime, ephemerally. Logs are displayed in the visual interface immediately and retained as long as Fenix remains open. Ephemeral logs are discarded when the application exits (which is not the same as stopping a server or running Fenix as a background process).

Each request log consists of a timestamp, request method, HTTP response status code, response time, and the path of the requested resource.

Realtime logs are typically sufficient for most development work, but a "Log to Disk" feature is available for permanent storage. This feature writes logs to a file and displays them in the realtime log viewer.

File Browser

Fenix ships with a file browser. If a request is made for a directory with no default file, the file browser will be displayed.

The slightly highlighted blue rows indicate a special viewer is enabled for these file types (see "Rendering" below).

Like most major web servers, the file browser provides basic access to files within a directory. Since Fenix also has a robust sharing feature, there may be sensitive situations where guest access to the file browser is undesirable. To accommodate these situations, the file browser can be turned off for all servers or individual servers.

Rendering: Markdown, JSON, XML, YML

Due to the widespread popularity of certain file formats, Fenix provides "pretty print" features for Markdown (.md), JSON, XML, and YAML/YML files. These can easily be toggled on/off to suit development needs.

For example, a raw/unrendered demo.yml file may display like:

When "Pretty YML" is on, a friendlier view of the file is rendered1.

Take note that common IDE features such as line numbers, code-collapsing, invisible character display, spacing, and theming are all available.


Fenix supports dynamic minification of JavaScript (ECMAScript 5) and CSS. At this time, ES2015 (ES6) minification is not yet possible. However; support will be added in a future update.

Minification is often used to reduce bandwidth and decrease response times. Minification is not typically done by a web server. It is more commonly part of a build process executed before files are made available on a server. Since Fenix must minify each file on the fly, it adds a small amount of processing time to each request. For this reason, assessing performance on the basis of minification is not recommended.

While dynamic minifcation is not a good performance indicator, Fenix minification provides a reliable method for understanding request size. This can be particularly helpful when working with large JavaScript and CSS files. Minification has proven to reduce file size by as much as 90%.

Minification can be toggled on/off per web server.


Entity tags are a method of optimizing cached content and site performance, which Fenix fully supports. Similar to minification, initial ETag resources will have minor additional processing time, but all subsequent requests will perform accordingly.

ETags can be toggled on/off per web server.

Compression (Gzip)

Dynamic compression using gzip can be toggled on/off per server. It is very rare for compression to provide any performance gain on a local development server since HTTP traffic never actually leaves the desktop. However; compression may have an impact on file size. By turning compression on and off, it is possible to determine this impact, which helps predict how much bandwidth any particular request may save (before ever shipping code to production).

Compression can be toggled on/off per web server.

CORS Support

Cross origin resource sharing (CORS) provides restrictions on the use of resources from an external domain. CORS affects the HTTP headers returned by a web server. Frontend developers often run into problems with CORS when using JSON services or REST API's. The most common scenario occurs when a frontend developer must create error handling for resources blocked by CORS restrictions. This can be an exercise in frustration when the developer must rely on a backend architect to modify a server configuration to test each use case. Fenix eliminates this pain by providing a CORS toggle option.

CORS can be toggled on/off for each web server.

Custom Headers

-- PRO Feature --

Fenix can send custom HTTP headers in response to all server requests, all of which are fully CORS supported (when applicable). Custom headers are often used when mocking a JSON API.


-- PRO Feature --

SSL can be toggled on/off per server in realtime. Using Fenix, developers do not need to create self-signed certificates, manage public/private keys, or deal with trust chains. While it is unnecessary, Fenix provides a global preferences section allowing developers to modify some details of SSL certificates if they choose to.

Fenix commercial editions ship with a native certificate authority, capable of automatically and immediately issuing, renewing, and revoking SSL certificates. It is a completely self-contained system that requires no administration or configuration. All generated certificates are domain aware and registered with the local certificate trust chain. In simple terms, developers will not receive browser warnings about untrusted certificates. Fenix automatically negotiates trusts with Google Chrome, Opera, Mozilla Firefox, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari. Other browsers based on any of the aforementioned are also supported.

*These are not LetsEncrypt certificates. Fenix certificates are specifically designed for desktop web server use only.

1. If the "light" theme is selected, the renderer will utilize a light theme as well.

results matching ""

    No results matching ""