Update W2 docs

2.0/docs/apps/endpoints.md

@@ -0,0 +1,28 @@
+# Endpoints
+
+Endpoints represent accessible endpoints to your app services. Endpoints consist of domains and/or ports. You can add configure domains, add custom domains, issue TLS certificates for a domain, publish/unpublish ports. 
+
+## Domains
+
+### Technical domains
+
+By default, Wodby will generate technical domains for services in your application that have enabled HTTP routes. The technical domains built in the following way – `<service-name>.<instance-name>.<app-name>.<org-name>.wodby.app`. We will also automatically issue Let's Encrypt certificates for technical domains. Additionally, the main service with http routes will have a technical domain without a service name – `<instance-name>.<app-name>.<org-name>.wodby.app`.
+
+### TLS Certificates
+
+Wodby provides a simple way to issue a TLS (SSL) certificate for a domain in your endpoint. Currently, we support only [Let's Encrypt](https://letsencrypt.org/) issuer. We will automatically renew Let's Encrypt certificates before they expire. You can also review all certificates that we issued from your organization settings page. 
+
+Custom certificates not currently supported.
+
+### Settings
+
+You can add so-called _Setting_ to your domains which represent individual configuration via [Ingress Nginx annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/).
+
+### Auths
+
+You can set up basic auth for your app (or for the specific app service or for the specific domain) from _"Apps > [App instance] > Endpoints > Auths"_` page. 
+
+## Ports
+
+Endpoint ports allow you to publish/unpublish a port that a service define. Ports have a protocol (`UDP` or `TCP`) and a port number.
+

2.0/docs/apps/instances.md

@@ -2,15 +2,15 @@
 
 Application instance is a single isolated copy of your application that deployed to a [kubernetes cluster](../kubernetes/index.md) and has:
 
-- [environment](env.md) (like production, staging)
-- [stack](stack.md) with a specific revision 
-- [routes](routes.md) to configure domains and public ports
-- [builds](builds.md) (if stack contains buildable services) and [deploys](deploys.md)
-- [backups](backups.md) and [imports](imports.md) (if stack contains services that provide such)
-- [app services](services.md) per each service that used to override stack configuration for this specific instance
-- live [logs streaming](logs.md) 
-- [cron](cron.md) schedules and jobs 
-- [tasks](tasks.md) history 
+- [Environment](env.md) (like production, staging)
+- [Stack](stack.md) with a specific revision 
+- [Endpoints](endpoints) to configure domains and public ports
+- [Builds](builds.md) (if stack contains buildable services) and [deploys](deploys.md)
+- [Backups](backups.md) and [imports](imports.md) (if stack contains services that provide such)
+- [App Services](services.md) per each service that used to override stack configuration for this specific instance
+- Live [logs streaming](logs.md) 
+- [Cron](cron.md) schedules and jobs 
+- [Tasks](tasks.md) history 
 
 ![](./images/instance.svg)
 

2.0/docs/services/index.md

@@ -2,55 +2,43 @@
 
 ## Overview
 
-Service (stack service) is a basic unit of managed infrastructure. Services have versions and manifests. Services can be added only by importing from a git repository. Most services have a template (Wodby template) and kubernetes manifests, however some types of services (like `config`) may not have kubernetes manifests. 
+Service is a basic unit of managed infrastructure. Services are versioned entities and have revisions. For each new update a service revision will be issued.  
 
-## Type
+Services can be added only by importing a template from a git repository. 
 
-Every service has a type. Type defines the behavior of a service and how it managed. There are several types of services:
-
-### `service`
-
-Stateless service, e.g. Nginx. Can be scaled up and down. Usually, services of this type have a template and kubernetes manifests
-
-### `db`
-
-Database servers, stateful services. Usually, services of this type have a template and kubernetes manifests
-
-### `infrastructure`
-
-Used in infrastructure applications, currently, can be added only by Wodby.
-
-### `storage`
-
-Used for distributed storage services, e.g. NFS, Rook or Longhorn. Usually, services of this type have a template and kubernetes manifests
-
-### `datastore`
-
-Memory storages like Redis and Memcached, stateful services. Usually, services of this type have a template and kubernetes manifests
+When a service added to a [stack](../stacks/index.md) we call it a _stack service,_ and it can be additionally [customized](../stacks/index.md#configuration) for a specific stack.
 
-### `search`
+## Template
 
-Stateful services, search engines like Elasticsearch and Solr Cloud.
-
-### `ssh`
-
-SSH server, usually used as derivative services
-
-### `proxy`
-
-Reverse proxy servers like Varnish and HAProxy
 
 ## Inheritance
 
 Services can inherit from other services. Inheritance is a way to extend a service with additional configuration. For example, you can create a new service that inherits from the `php` service and add additional environment variables or links to it.
 
 ## Derivatives
 
-Derivatives are services that created from other services. For example, ssh server service added as a derivative to PHP-FPM. 
+Derivatives are services that created from other services. For example, ssh server service added as a derivative to PHP-FPM.
 
 ## Options
 
-Options usually used to represent service versions, e.g. Nginx has two options: `1.23` and `1.22`. A service can have multiple options, specify one of them as default and add to some of them End of Life (EOL) date. 
+Options usually used to represent service versions, e.g. Nginx has two options: `1.23` and `1.22`. A service can have multiple options, specify one of them as default and add to some of them End of Life (EOL) date.
 
 ## Settings
 
+### Reference
+
+#### Type
+
+Every service has a type. Type defines the behavior of a service and how it managed. There are several types of services:
+
+- `service` stateless (e.g. Nginx) or a stateful (e.g. OpenSMTPD) service. Can be scalable
+- `db` database servers, stateful services
+- `infrastructure` used in infrastructure applications, currently, can be added only by Wodby.
+- `storage` used for distributed storage services, e.g. NFS or Rook
+- `datastore` memory storages like Redis and Memcached, stateful services
+- `search` stateful services, search engines like Elasticsearch and Solr Cloud.
+- `ssh` SSH server, usually used as derivative services
+
+#### Options
+
+#### Endpoints

2.0/docs/stacks/configuration.md

@@ -0,0 +1,101 @@
+# Stack Configuration
+
+Unlike Wodby 1.0 there's no differences between managed and custom stacks. All stacks are custom and supposed to be changed to your needs. And at the same time all stacks get updates from the included managed services.
+
+## Environment Variables
+
+You can add stack-wide environment variables from "[Stack] > Configure > Env vars" page. Such environment variables will be added to all app services' kubernetes resources during deployment in app instances that use this stack revision.
+
+An environment variable can be optionally marked as secret, when "Secret" selected the environment variable value will be stored in a kubernetes secret and won't be shown in Wodby dashboard.
+
+You can optionally limit a variable to a certain environment type, when set env var will be added only to app instances that use the selected environment type.
+
+## Annotations
+
+You can add stack-wide annotations from "[Stack] > Configure > Annotations" page. Such annotations will be added to all app services' kubernetes resources during deployment in app instances that use this stack revision.
+
+You can optionally limit an annotation to a certain environment type, when set annotations will be added only to app instances that use the selected environment type.
+
+## Tokens
+
+You can add stack-wide tokens from "[Stack] > Configure > Tokens" page. Such tokens will be added to all app services in app instances that use this stack revision.
+
+Tokens can either have a plain value or a regular expression that will be used to generate a random secret value when an app services created/updated. You can use tokens in environment variables' values.
+
+You can optionally limit a token to a certain environment type, when set tokens will be added only to app instances that use the selected environment type.
+
+## Stack Services
+
+A stack always includes a specific revision of a service. When a new service revision issued corresponding stacks can be updated to switch to the latest revision of a service.
+
+Each service in a stack can be configured under "[Stack] > Configure > Stack services > [Service]". A service can be enabled or disabled, set as mandatory or optional. When set mandatory it cannot be excluded during new app creation.
+
+Only one service can be set as main, in this case, if a service has http endpoints, the app instance's main technical domain will target the main endpoint of the main app service.
+
+### Replicas
+
+You can change number of replicas per service, not available for external services.
+
+### Integrations
+
+If a service provides integrations in its manifest, you can link a specific integration from your project that satisfies requirements of a service integration. Example: OpenSMTPD service allows `smtp` typed integrations to be connected to use as relay, a user has _Brevo_ integration in her organization and selects it under "[Stack] > Configure > Stack services > OpenSMTPD > Integrations", then creates a new app with this Stack, the app will already have _Brevo_ integration connected and will use it to send emails from OpenSMTPD.
+
+Additionally, to all non-external services you can add [Variable](../integrations/variable.md) integrations.
+
+### Environment Variables
+
+You can add service-specific environment variables from _"[Stack] > Configure > Stack services > [Service] > Env vars"_ page. Such environment variables will be added to the corresponding app service's kubernetes resources during deployment in app instances that use this stack revision.
+
+An environment variable can be optionally marked as secret, when "Secret" selected the environment variable value will be stored in a kubernetes secret and won't be shown in Wodby dashboard.
+
+You can optionally limit a variable to a certain environment type, when set env var will be added only to app instances that use the selected environment type.
+
+### Resources
+
+For non-external services you can set up resources requests and limits from _"[Stack] > Configure > Stack services > [Service] > Resources"_ page. Resources requests and limits correspond to [kubernetes resources request and limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run).
+
+#### Request
+
+You may set up request for CPU and memory. Requests help your cluster to schedule and distribute workloads across the nodes. When resources request specified your deployments may fail if there are not enough resources on the cluster. CPU requests are mandatory for scalability.
+
+#### Limit
+
+You may set up limits for CPU and memory. Resources limits are useful to limit burstable workloads and their effect on other resources on the same cluster.
+
+### Options
+
+Options represent different versions or variant of a service. Some stacks may limit which options are supported (enabled) to match with compatibility requirements or to exclude end of life (EOL) versions. You can change the default option and enabled options for a service in your stack from _"[Stack] > Configure > Stack services > [Service] > Options"_ page.
+
+### Links
+
+A service may provide a _link_, it's a way to represent integration of a service with another service. The simplest example would be Nginx's service link to upstream/backend (e.g. PHP-FPM). Some links are mandatory, some are optional. If a link is mandatory, a stack must specify which service from the stack should be used for a specific links. For example, in Drupal stack the PHP service requires _Database_ link, you can set it to use container-based _MariaDB_ or an external _Cloud MySQL_.
+
+You may change links in your stack from _"[Stack] > Configure > Stack services > [Service] > Links"_ page.
+
+### Volumes
+
+You can change the size of volumes provided by a service for your stack from _"[Stack] > Configure > Stack services > [Service] > Volumes"_ page.
+
+### Settings
+
+You can override settings provided by a service for your stack from _"[Stack] > Configure > Stack services > [Service] > Setting"_ page. Settings that source value from links cannot be edited.
+
+### Cron
+
+You can create cron schedules for a service in your stack from _"[Stack] > Configure > Stack services > [Service] > Cron"_ page. Cron schedule must have a name, command and schedule. Schedule supports full crontab format (e.g. `0 0 * * *` for every day on midnight) and `@hourly`, `@daily` formats. A container with a specified command will be run according to the schedule.
+
+You can optionally limit a cron schedule to a certain environment type, when set the cron will run only on app instances that use the selected environment type.
+
+### Tokens
+
+You can add service-specific tokens for your stack from "[Stack] > Configure > Stack services > [Service] > Tokens" page. Such tokens will be added to a corresponding app service in app instances that use this stack revision.
+
+Tokens can either have a plain value or a regular expression that will be used to generate a random secret value when an app services created/updated. You can use tokens in environment variables' values.
+
+You can optionally limit a token to a certain environment type, when set tokens will be added only to app instances that use the selected environment type.
+
+### Annotations
+
+You can add service-specific annotations from "[Stack] > Configure > Stack services > [Service] > Annotations" page. Such annotations will be added to the corresponding app service's kubernetes resources during deployment in app instances that use this stack revision.
+
+You can optionally limit an annotation to a certain environment type, when set annotations will be added only to app instances that use the selected environment type.