Billing system that will support creditcard payment. The billing system will accumulate charges over the course of a month, and after the months end, it will send out an invoice and try to charge the creditcard, or added credits to the account.

The billing system need to support various discounts.

Charges should occur on a second base, so users are only charged for the seconds a specific product is running.

Web replica

The idea for web replica monitoring is to get insight into resource usage.

History view

The following historical view are suggested, with the proposed resolution

Proposed metrics

We suggest the following metrics

Database metrics

Not planned yet

Redis metrics

Not planned yet

Allow people to delete

• User
• Organization
• Application
• Environment
• Database
• Redis

Allow users to create Let's encrypt certificate for custom domains.

Run a command for a specific application. See #38

To allow for more people to use payed services from the Cloud project, it'd be nice to be able to pay with PayPal instead of just Credit Card

Figure out, and develop tools to migrate from Cloud 1 to Cloud 2.

Allow people to reboot a replica

Allow users to create and scale database servers. A database server is linked to an organization, and after this, the user can link environments to the specific server.

More info to follow

Personally, I'd love to have a quick and easy way to see what exact git commit my app is running at on the dashboard.

I mocked up 2 small designs (see screenshots)

For Cloud 2 we will support multiple replicas, and custom Docker files. This will make a change for how we will handle building containers.

As Cloud 2 is still early, this is still work in progress and can change with time.

cloud.yml file

In cloud 2 we will completely remove the cloud.yml file, as we can achieve the needed functionality without.

Multiple replicas

In Cloud 2 it will be possible to have multiple replicas running with different docker templates, per default all applications will have a web replica, which is the default for running the application. Other types could be offloading large tasks to a queue replica. More information on this system will be added during the beta phase.

Custom docker files

Per default Cloud 2 will always use the latest Swift release to build the project.

All Vapor templates will be updated to include a Dockerfile that will be used during build. If a different Swift version is required, people will need to add a different Dockerfile to their projects.

The Dockerfile naming should be like this:

<replicaName>.Dockerfile

For example

web.Dockerfile

Per default all docker files will automatically be loaded on port 80, so all Vapor apps will be set to use port 80 instead of 8080. A different port can be set from the dashboard on the replica settings once we release multiple replicas in the beta.

Allow users to create developer tokens for use with the public API.

When creating the token, the user should be able to set how long it should be able to live.

Allow users to create and scale redis servers. A redis server is linked to an environment, and can only be used for this specific environment.

Allow users to enable 2FA on their account. It should also be able to show under an organization which users have 2FA enabled.

2FA will only be app based, no SMS

Publish OpenAPI Spec for integrate with the Cloud API

Allow users to create a domain. When creating a domain, you should also be able to set path based routing. So e.g.:

mydomain.com/foo -> foo(application)
mydomain.com/bar -> bar(application)

We should have an easy way to provide feedback from Vapor Cloud 2. This should also be available after we launch Cloud 2, so people can give easy feedback, especially from the Dashboard.

The best system would be a button e.g. In the footer, that gives a popup. After sending, it should create a ticket in our new support system.

However don't think we should prioritize the ticket system right now, maybe it will just send us an email for now @tanner0101 what do you think?

Show a list of recent releases for an application.

This will show:

• date
• who did the releases
• Type (Scale, Deploy etc.)
• Message (Including git hash for deploy etc.)

We are now quite far in the planning of our new Jobs system. This is the system used for running both one time jobs and periodic jobs (Cronjobs)

One-time jobs

One-time jobs is a command you run one time in your app, this can e.g. Be a revert or similar command.
When starting this, the command will start running in the background, it's then possible to go in and start following the log output of the command (The toolbox and dashboard does this automatically)

Completed jobs will be visible in the dashboard for 30 days after completion, after this, the details of that specific job will be deleted.

Cronjobs

Cronjobs are a way to specify periodic jobs to run in specified times. This can for example be every second monday of every month, or even simpler every 5 minutes.

Cronjobs can be created either from the dashboard or toolbox. The system will store the details of the last 10 run though of each job.

Payment of jobs

Both types of jobs will start up a separate replica to run the specified command. This will give a slight delay in execution, however it will make sure that the web requests of an application aren't affected.

Billing is like replica payment, so prorated down to the second the job is running, and it will be possible to decide which plan the job should run on.