For organizations
Provide internal teams with managed virtual machines for applications, development, teaching, and research while retaining infrastructure and policy control.
Cloud Server
Available on request
Managed Cloud Server for your teams or customers, on infrastructure you control.
WECORE Cloud deploys and operates a managed virtual-machine service for your teams or customers, with governed self-service and usage metering.
- Runs on infrastructure you own or lease
- Governed user access
- Full root access
- Browser terminal and desktop
- Only the server's owner can connect
The configurator shows what authorized users can choose after Cloud Server is deployed for your organization.
What your users can configure
Balanced vCPU and RAM
- vCPU
- 2 vCPU
- Memory
- 4 GB RAM
- Storage
- 60 GB storage
- Network
- Defined by policy
Illustrative post-deployment preview. Your infrastructure team defines the actual families, sizes, storage, and network policies available to authorized users.
A Cloud Server service for your organization or customers
Commission a governed VM service on infrastructure your organization owns or leases; the product controls below show what authorized users receive after deployment.
For service providers
Offer a branded IaaS compute service on your server capacity, with a VM catalog, tenant controls, metering, and operational support.
What your users can do
Choose an approved image and size, create a VM, receive access credentials, and manage its lifecycle from the browser or API.
What your infrastructure team gets
Control the image catalog, compute sizes, networks, quotas, access policies, usage records, and service lifecycle.
How WECORE deploys and operates it
We integrate Cloud Server with your OpenStack infrastructure, configure the service catalog and policies with your team, validate it, and provide ongoing operations. If you don't run a cloud foundation yet, the engagement can include deploying the open-source infrastructure layer the service runs on.
- Browser Terminal and desktop access
- Owner-only Authorization on every request
- Usage-based Runtime and allocated resources
- Activity Durable lifecycle record
What your users can choose after deployment.
Your infrastructure team approves the compute families and sizes made available to authorized users.
General Purpose
Balanced compute for most apps
An even mix of vCPU and RAM for web servers, APIs, small databases, and dev/staging. A sensible default when you're not sure where to start.
- vCPU 1 – 16
- RAM 4 – 64 GB
- Storage Defined per deployment
Balanced price-performance
See the service context →
CPU-Optimized
Dedicated cores for CPU-heavy workloads
Higher core-to-RAM ratio for CPU-bound work: media transcoding, data processing, batch jobs, CI runners, and high-traffic front ends.
- vCPU 2 – 32
- RAM 4 – 64 GB
- Storage Defined per deployment
Throughput per core
See the service context →
Memory-Optimized
RAM for data-heavy services
More memory per core for in-memory caches, large databases, analytics, and real-time data. Keep active data in RAM, not on disk.
- vCPU 2 – 32
- RAM 16 – 256 GB
- Storage Defined per deployment
Capacity per core
See the service context →
Usage metering records runtime and allocated resources according to the commercial model agreed for your deployment.
After deployment
Three steps to a running server
Authorized users can create a server through the panel or API, within the policies and quotas your infrastructure team sets.
-
1
Choose an image
Pick from the Linux distributions, pre-installed apps, and custom images your infrastructure team has approved.
-
2
Choose a size
Select a family and size. The vCPU, memory, and storage combinations available to users are defined for each deployment.
-
3
Create and follow readiness
Create the server with full root access, then follow its durable activity record as addressing and browser-access checks apply the policies set for your deployment.
After deployment
Approved images for your users
Your organization chooses which validated operating-system images and access capabilities enter the deployment catalog.
Browser-access support is declared per image; the final catalog is defined for the deployment.
- Ubuntu LTS: terminal + desktop
- Rocky Linux: terminal + desktop
- AlmaLinux: terminal + desktop
- Debian: terminal only
What Cloud Server gives your teams
Governed access, observable readiness, and lifecycle control on your infrastructure
Owner-authorized browser access
Every session is authenticated at one front door and authorized against the requested server's owner.
No inbound browser-access port
The server dials out to the edge, so terminal and desktop access do not require an inbound display port on the server.
Usage-based commercial model
Metering follows runtime and allocated resources; the exact rating and network policy are agreed for the deployment.
Readiness with a next action
If a server isn't ready, you see exactly which step needs attention (proxy, address, security group, or guest setup) and the next action.
Volumes and snapshots
Authorized users can create, attach, detach, and delete block volumes, and list or delete snapshots.
Durable activity and live status
Each create request has a durable history, while status changes update the open page with bounded refresh as a fallback.
User capabilities
Extend approved servers with governed add-ons
After deployment, authorized users can attach the resources and lifecycle options enabled by your infrastructure team.
Block storage
Create, attach, detach, and delete additional volumes within project policy.
Snapshots
List and delete snapshots according to the storage policy enabled for the project.
Address policy
Use automatic, required, disabled, or infrastructure-team-managed addressing as configured for the deployment.
Managed security group
Maintain only the browser-access rules required by policy while preserving rules added by the infrastructure team.
Native console
Open the platform console when a server needs direct inspection.
Boot-log preview
Read a redacted boot-log preview when a server does not become ready.
Browser terminal
Request and track a terminal session independently from the graphical desktop.
Browser desktop
Request a graphical desktop on supported images and follow its own readiness state.
What your users can run
What teams run on Cloud Server
Make approved Cloud Server configurations available for the workload categories your organization supports.
Web apps & APIs
Host web servers, REST/GraphQL APIs, and SaaS back ends with room to scale horizontally behind a load balancer.
Databases
Run approved database services on memory-oriented configurations with attached block storage and project network policy.
Dev & staging
Create temporary environments when you need them and remove them when you're done, within the images, sizes, and quota approved for your project.
CI & batch jobs
Add CPU-optimized servers at peak for build pipelines, data processing, and scheduled jobs, then remove them when the run is complete.
Game & media servers
Run game or media back ends on approved configurations, with addressing and network policy set by your infrastructure team.
Self-hosted tools
Run your own GitLab, Nextcloud, monitoring stack, or VPN with full root control and clear usage-based billing.
Side-by-side with our other products
Each WECORE product is designed for a different kind of workload
| Product | Best for | Infrastructure | Storage | Billing |
|---|---|---|---|---|
| Cloud Server Compute |
General compute, web apps, workloads with temporary demand spikes, databases | Virtual machines with allocated resources | Deployment-defined block storage | Usage-based |
| Dedicated Cloud | Dedicated IaaS, regulated workloads, development platforms, and customer cloud services | Dedicated bare metal, single tenant | Software-defined storage | Defined per deployment |
| HPC platform | Scientific compute, simulations, research, batch jobs | Managed HPC platform | Project storage | Defined per deployment |
FAQ
Planning Cloud Server for your organization
What you commission, what users receive, and what your infrastructure team controls
You commission a managed virtual-machine service on infrastructure you control, with a catalog, governance model, metering, and operations tailored to your organization.
WECORE deploys the service and operates the agreed platform responsibilities. Your infrastructure team owns the image catalog, families and sizes, network policies, and quotas; your users own the servers they create and the data on them. WECORE monitors service health, coordinates upgrades, and works incidents within the responsibility split agreed for your deployment. Panel access is role-based, and administrative actions are recorded in tamper-evident audit records. Hardware and facility stay with the infrastructure owner unless included separately; the pricing page carries the full responsibility and access model.
After deployment, metering records runtime and allocated resources. Your commercial model, quotas, and outbound-traffic policy are defined for the engagement.
Cloud Server provides governed VMs for your teams or tenants. Dedicated Cloud is the provider-focused service for offering complete dedicated OpenStack and Ceph clouds to customers.
You can: Cloud Server exists for teams that don't want to own that layer. What the engagement adds to plain OpenStack and Horizon is the operated product around the service: owner-authorized browser access with no inbound display port, readiness reporting with a next action, metering tied to the agreed commercial model, and agreed operations for upgrades and incidents.
The server has a durable activity record and live status updates. If browser access isn't ready, the page names the blocking step and the next repair action.
For browser access, Ubuntu LTS, Rocky Linux, and AlmaLinux support terminal and desktop; Debian supports the terminal. Windows desktops are delivered by Cloud Desktop, not Cloud Server. Your infrastructure team controls the validated images and capabilities users can select.
Your deployment defines public or private addressing, security policies, outbound-traffic allowances, and any additional IP options. Users receive only the network choices approved for their project.
Yes, within project permissions. Users can create, attach, detach, and delete block volumes, and list or delete snapshots.
No. The server dials out to the configured edge; each request is then authenticated and authorized against the server owner before the session opens.
Further reading Cloud Server: governed virtual servers on your OpenStack
Cloud Server for your infrastructure
Plan a managed VM service for your teams or customers.
Tell us about your infrastructure, intended users, governance requirements, and expected workloads. In a briefing we can walk through the live panel, from server creation to readiness to a browser session.