Audit Logs

Trace all actions in your account; from API requests to change of state from instances, services, volumes and more.

IP whitelisting for services

For services that are intended to be reachable only from certain IPs/IP ranges, adding the ability for whitelisting would improve security.

Changing properties of service groups after creation

Currently, once you create a service group all properties are fixed. You have to re-create the service group if you want to change something. This is problematic especially for service groups, where you want to add/remove/update services or domains after creation because it means you also have to re-create the instances. Furthermore, you cannot avoid a downtime in this case. It should thus be possible to change settings of service groups without having to re-create the group.

Connection-based autoscale metrics

Currently, autoscale allows policies based on CPU utilization only. It should be possible to also create policies based on network load. More specifically: Requests / second (or connections for non-HTTP services) Number of in-flight requests (or in-flight connections for non-HTTP services)

Environmental Variable Groups

Manage environment variables in a group of variables and be able to reference the group when creating an instance.

Let applications control when scale-to-zero is allowed

Scale-to-zero is currently based on a cooldown period. This means If the application is performing a background task, which is running after the response has been send to the last request, the background task will be canceled if it takes too long. It would be desirable to be able to disable/enable scale-to-zero from the application to allow background tasks to finish. This would be achieved using a pseudofs controls, e.g.: import "fmt" func main() { // echo 1 > /sys/kraftcloud/scale-to-zero _ = os.WriteFile("/sys/kraftcloud/scale-to-zero", []byte{"1\n"}, 0644) } and via our native SDKs e.g. import ( kcp "github.com/kraftcloud/go-sdk/platform" ) func main() { _ = kcp.ScaleToZero() }

Allow scale-to-zero for multiple instances in a service group

Currently, scale-to-zero is implemented as part of autoscale when the service group is scaled down to 0 instances. This means you cannot have multiple instances scaled-to-zero for the same service. However, to reduce scaling latency to a minimum it would be preferable to have scale-to-zero as a property on the instance, completely independent of the periodic policy-based autoscale. This would allow you to have a set of replicas all in standby and immediately available when needed.

Dynamic Memory Ballooning

This feature tracks the ability to automatically grow and shrink memory based on application usage.

Virtual TTY Console

Provide support to connect to Unikraft-based instances and execute various built-in commands like: listing open sockets / connections checking network and DNS configuration pinging remote hosts browsing the file system

Support non-PIE Executable Binaries

Multi-core Linux Instances

This feature allows creating and running Linux-based instances with multiple vCPUs. Currently, all instances irrespective of type are limited to 1 vCPU.

Multi-process Applications

This feature allows applications on Unikraft to use the fork and vfork system calls to spawn processes, in cases where the fork is followed by an exec system call. This will allow executing many multi-process applications as well as allow shells like bash to execute scripts on Unikraft.

Shared Read-only Volumes

This feature allows multiple instances to mount the same volume in read-only mode.

Instance Usage Statistics

This feature tracks the ability to monitor application instance network traffic, e.g. network ingress/egress (bytes); CPU utilization; and memory utilization.

Wildcard Domain Support

This feature allows using a wildcard domain, e.g. *.example.com.

Instance Restart Policies

This feature allows for setting different actions to occur when an instance's state changes from running to either restart "never", "always" or only "on-failure".

Stateful Cold-Starts

This feature allows application instances to be suspended in a manner that saves their state; allowing them to be resumed (in milliseconds).

Set environmental variables and arguments after creating an instance

Currently it is only possible to set environmental variables and application arguments one time and that's during instance creation. It should be possible to set new environmental variables and application arguments after an instance has been created (e.g. when it is first started or after restarted).