EPYC VDS / EPYC for persistent services
EPYC VDS
Keep the whole service in view.
Build a VDS environment for the services your application depends on. Compare AMD EPYC configuration, memory and NVMe capacity, then organize your database, API and workers around a measured resource budget.
Resource ranges refer to the VDS plans below, not to physical CPU specifications.
Confirm the processor configuration and data-center availability before ordering. A VDS is a virtual server; exclusive physical cores are not implied by its name.
Choose your EPYC VDS resources
Compare CPU, RAM and NVMe capacity in one table. Choose the resource level that fits your project.
DE EPYC VDS-2Balanced performance for websites and small applications.1× IPv4 address
Prices are shown per month. Final pricing, optional services and available data center locations are confirmed at checkout. Switching locations here changes the displayed region; please confirm your preferred location during ordering.
CPU / RAM / NVMe
Find your starting point.
Match your workload and expected activity to the existing VDS plans.
A sizing guide, not a capacity guarantee. Allow for your operating system, software and licenses; test with your own workload.
DE EPYC VDS-1
$19.99 /mo
2 vCPU · 8 GB · 100 GB · 5 TB
02 / BUILT AROUND YOUR WORKLOAD
A resource plan for the complete service.
Persistent applications need a home for live requests, working data and the tasks that keep them running.
Service processes
Configure APIs, workers and scheduled jobs with separate accounts, limits and maintenance routines.
Working data
Account for database memory, cache and disk growth together instead of sizing only the application code.
Operational continuity
Record the configuration needed to restart services and recover application data after a failed release.
Your chosen region
Choose from the listed regions and confirm the final platform and data center in the order.
Clear resource levels
Compare four explicit CPU, RAM and NVMe combinations against your application's requirements.
Service management
Use the customer account to access service information and the available server-management interfaces.
03 / A CLOSER LOOK
What does an EPYC VDS provide?
An EPYC VDS is a virtual server using an AMD EPYC host platform. Your plan defines the vCPU, RAM and storage available to the guest system. It does not provide the whole physical host simply because the product is called VDS.
Use it to assemble compatible services in an environment you administer. For a growing stack, monitor the interactions between the application, workers and database before choosing the next resource level.
Compare VDS plans ↗Use cases
Where your EPYC VDS fits.
Plan the environment around the data, users and daily work of your project.
Persistent APIs
Keep application endpoints and their configuration in an environment with an explicit resource budget.
- API / web service
- Workers / cache
- Database / storage
Database services
Plan working memory, retained data and independent recovery copies.
Queue workers
Control worker concurrency so background activity can coexist with live requests.
Business integrations
Host compatible connectors and scheduled exchanges with controlled credentials.
Internal services
Run authorized team tools with documented access and maintenance.
Data processing
Schedule compatible batch jobs around the capacity used by persistent services.
Compare
Choose the platform for your service stack.
Compare compatible workflows, actual resources and software requirements before choosing the server.
EPYC VDS
Plan resources across the services that keep your application running.
- APIs and service processes
- Databases and caches
- Queues and background jobs
Ryzen VDS
Consider the alternative platform for your application and development workflow.
- Web and application requests
- Build and test processes
- CPU-sensitive application loops
A workflow comparison, not a benchmark. Actual performance depends on the CPU model, allocated resources and application.
| Consideration | This platform | Alternative |
|---|---|---|
| CPU platform | AMD EPYC | AMD Ryzen on Ryzen VDS |
| Guest environment | Selected compatible operating system | Compatibility also depends on the chosen OS |
| Capacity planning | Size the complete stack | Compare real CPU, RAM and storage needs |
How it works
Your own operating environment.
A physical host supplies compute, memory and storage. A virtualization layer allocates resources to separate virtual machines. Each VDS runs its own operating system and applications. Actual resource-allocation guarantees depend on the selected service configuration.
CPU / RAM / NVMe
Size the whole environment.
Choose resources for your operating system and supporting services as well as the application itself. Leave room for updates and workload peaks.
CPU and concurrency
Count simultaneous requests, background workers and scheduled jobs. Measure a representative workload before choosing a resource level; the processor name alone does not describe how your application uses CPU time.
RAM and active data
Allow memory for the operating system, runtime, database and cache. A graphical environment or control panel also needs resources. Consider the complete working set rather than assigning all RAM to one process.
NVMe and growth
Include application files, databases, logs and temporary data. Monitor free space and retention. Server storage and an independent backup are different things; define both capacity and recovery needs.
DE / NL
Two regions. A deliberate choice.
Consider users, connected services and operational requirements. Test from your audience's networks rather than treating a location name as a latency guarantee.
Germany
FrankfurtConsider Central European audiences and the location of services your application connects to.
Netherlands
AmsterdamCompare the Netherlands for European traffic and connections to your other application services.
The selector changes the displayed region. Confirm the actual data center, processor platform and operating-system options in your order.
Guide
Understand the platform before deployment.
Platform and compatibility
The virtual machine boundary defines the environment you administer. Inside it, you manage application users, services and data. The host platform and the guest allocation are different layers; confirm the allocation terms when a workload requires a specific isolation model.
Workload planning
Review resource consumption at the same time each day and during traffic peaks. Compare API response time, database working memory and the time spent clearing queues. A balanced change addresses the constrained component rather than increasing every resource blindly.
Server operation
Treat deployment as the start of an operating process. Decide who maintains the operating system, who can change the application and how a failed release is recovered. Record those responsibilities with the relevant configuration, so routine maintenance does not depend on a single person remembering every step.
Server operation
Plan beyond the first deployment.
Administrator access gives you flexibility. Running a server also needs clear procedures for configuration, maintenance and recovery.
Access and accounts
Create the users you need, protect administrator access and review publicly exposed services. Keep credentials out of application code.
Updates and changes
Check compatibility before major updates. Record configuration changes and test application upgrades in a separate environment when practical.
Backup and recovery
Define what is copied, where it is stored and how to restore it. Test a recovery instead of assuming a saved backup is usable.
Monitoring and support
Watch resource usage and application health. Keep useful diagnostic information and agree the scope of any additional management assistance.
PRACTICAL GUIDE
Plan maintenance alongside live traffic.
Background jobs, database maintenance and updates consume the same finite resources as live requests. Observe a full operating cycle rather than relying on one idle reading. Define the periods when heavy jobs can run.
When changing a resource level, preserve the relevant application metrics and compare them after the change. Keep a tested recovery procedure and verify the available upgrade path before planning a production expansion.
04 / GETTING STARTED
From a plan to your own environment.
- 01
Size your VDS
Compare CPU, memory and NVMe capacity with the requirements of your applications.
- 02
Check the details
Confirm the location, operating system and any software licenses during ordering.
- 03
Make it yours
Configure access, updates and backups before moving your workload to the server.
05 / YOUR QUESTIONS
EPYC VDS
questions, answered.
Is an EPYC VDS a complete dedicated server?
No. It is a virtual server with the resources described by its plan. Confirm any exclusive resource requirements separately.
Can I run an application and database together?
Yes, when their combined requirements fit the selected environment. Include operating-system, cache and maintenance needs and test the real workload.
How should I choose an EPYC VDS location?
Consider your users and the services the application connects to. Measure relevant network paths and confirm the final EPYC configuration during ordering.
How should I plan backups?
Keep an independent copy of important data and configuration. Confirm provider backup options separately, define retention and test the restore procedure.
Can I change resources later?
Review the available upgrade path and any restart or migration requirements with support before ordering.
What should I check before payment?
Review final CPU, RAM, disk, location, operating system, licenses and billing total. Confirm any additional service you need.
Should every resource increase together on an EPYC VDS?
Base changes on measured constraints. Database memory, CPU saturation, disk growth or an external dependency may be responsible; expanding unrelated resources may not resolve the issue.
VDS.NET / YOUR NEXT DEPLOYMENT