Sentreva Internet Hizmetleri and the service records behind a Turkish network name

Summary

• Sentreva's public evidence supports a bounded reading: a Turkish hosting, domain, VPS/VDS, dedicated-server, software and licensing provider with account and support workflows, not a broadly proven global internet-services platform.
• AS199797 is visible in RIPE and BGP records as a small routed network identity. Current public views show one originated IPv4 /24, no visible IPv6 announcement, a Pentech-linked address-block context, transit dependency around AS48678, and valid RPKI origin authorization for 188.132.151.0/24.
• Sentreva's website is delivered through Cloudflare and uses external mail infrastructure signals, so the public site cannot be treated as a live performance test of AS199797 or of Sentreva-operated hosting infrastructure.
• The operational questions for buyers are record questions: account ownership, support escalation, routing-policy freshness, backup responsibility, migration limits, status transparency and whether Turkish locality is contractual, physical, network-level or merely a product label.
• Public evidence cannot establish uptime, customer counts, traffic volume, data-center control, private architecture, real support response quality or backup execution. Those would require customer contracts, privileged access, independent monitoring or controlled product testing.

The label is too broad; the records are more useful

Sentreva Internet Hizmetleri can be described in the broad language that most hosting providers use. It sells domain registration, web hosting, virtual private servers, virtual dedicated servers, physical server rental, software and licensing. It presents Turkey-location services. It gives a phone number, an email contact, a login path and a support-ticket path. Its site contains the familiar promises of free SSL certificates, migration help, expert management, updated hardware and software, security precautions and full-performance servers. That is the public storefront.

For a technology buyer, however, the storefront is only the first layer. Hosting and server providers do not become dependable because their categories are familiar. They become dependable when the records behind those categories stay aligned. A domain order needs a real account owner, accurate contact email, a renewals trail and a recovery path. A hosting account needs provisioning records, limits, backups, migration notes and abuse handling. A VPS needs an identity, a root password, an IP assignment, billing state, support history and a clear boundary between provider responsibility and customer responsibility.

A routed network needs an autonomous-system entity, route objects, origin authorization, upstream policy and maintainers that stay current. A support operation needs tickets, knowledge, escalation and evidence that customers can recover from routine mistakes before those mistakes become incidents.

That is why Sentreva is more interesting as a record system than as another entry in the crowded internet-services market. The company is small in the public network record. Current routing evidence around AS199797 points to one visible IPv4 prefix, 188.132.151.0/24, and no visible IPv6 announcement. The RIPE organization entity identifies Sentreva Internet Hizmetleri Anonim Sirketi in Turkey. The aut-num entity uses the AS name sentreva, references the Sentreva organization record and a sponsoring organization, and lists import and export policy lines for AS48678 and AS9121. Public route views and third-party ASN pages converge on a narrower current picture: the visible routed footprint is one /24, with AS48678 Pentech appearing as the key upstream in the current public view, and with the address-block context itself carrying a Pentech description in RIPE's inetnum record.

This is not a criticism by itself. Many service providers operate with modest routing footprints, leased or assigned address blocks, upstream transit, Cloudflare-fronted public sites and external mail services. The important point is that each layer carries different evidence. A company website can show what Sentreva offers. A RIPE organization entity can show who holds a registry identity. A route object can show the intended origin for a prefix. BGP collectors can show what is observed. RPKI can show whether the visible origin is authorized. DNS and HTTP headers can show how the company's own site is reached.

None of those records, alone, proves customer experience.

Sentreva should therefore be judged through a narrower and more useful lens. The issue is not whether the company can be filed under a broad internet-services label. It can. The issue is whether the records behind its service, account, routing, support and recovery surfaces stay fresh, governed, attributable, queryable and recoverable under repeated operational use. A small provider can be a perfectly sensible choice for a customer that values local support, Turkish billing context, familiar hosting panels and lower coordination burden.

It can also become a source of risk if records drift, backups are assumed rather than arranged, routing dependencies are opaque, or the support queue becomes the only way to recover account access during an outage.

What Sentreva says it sells

Sentreva's own pages give the cleanest boundary for the service catalog. The homepage and category navigation emphasize domains, web hosting, VPS/VDS, physical servers, software and corporate information. The about page states that the company was established in Istanbul on January 11, 2023 through the merger of two companies, and that it provides web hosting, virtual and physical server, software and licensing services to companies and individuals seeking internet visibility and IT services.

The contact page gives a legal and administrative identity: Sentreva Internet Hizmetleri A.S., Kozyatagi tax office, tax number 7611104523, trade registry number 436199-5, MERSIS number 0761110452300001, a phone number, an email address and an Atasehir/Istanbul address.

That identity matters because hosting is not a purely technical purchase. Customers often discover the value of a provider's corporate and support records only when something routine goes wrong: an invoice fails, a domain is close to expiry, a server password is lost, a migration breaks, a backup is needed, an abuse complaint arrives, a user leaves the company, a credit card changes, or an IP address appears on a blocklist. In those moments, the buyer is no longer buying bandwidth or disk.

It is relying on a support and account operation to identify the rightful customer, understand the service state, coordinate with registries or upstream providers, and restore a usable configuration without making the incident worse.

The service agreement shows how much of Sentreva's operating surface is record driven. It says that orders are installed after fraud checks and payment. For credit-card payments, domain, web-hosting and reseller-hosting accounts may be automatic, but setup can take up to 48 hours if there is a problem. For bank transfer or EFT, setup can take up to two business days. VDS and dedicated-server setup is stated as 48 hours unless otherwise specified. Software and license delivery is up to one week unless otherwise stated.

Customers are responsible for providing and maintaining a working email address, and messages sent to that address are treated as delivered. Incorrect or incomplete order information can lead to cancellation and refund limits. Sentreva also reserves the ability to request identity or card documentation for security checks.

Those clauses are not decorative legal text. They are the operational skeleton of the service. They tell the buyer that provisioning is not just a button; it depends on payment status, fraud screening, account contact quality and service category. They also tell the buyer that the customer's own records become part of Sentreva's control plane. If the customer loses access to the account email, ignores notices, registers with the wrong details or cannot prove identity during a fraud check, the service can drift into a disputed state.

That is a common hosting-market reality, but Sentreva's terms make it explicit enough that buyers should plan for it.

The product pages add market context. The corporate SSD hosting page describes high-performance servers, corporate support, free cPanel-to-cPanel migration for hosting and server orders, expert management and security support, modern updated hardware and software, and optimization/security precautions. The Turkey-location VPS/VDS page lists package tiers with CPU, memory, SSD disk, monthly traffic and IP-address terms, and repeats the support, migration, updated-technology and security language.

The Turkey-location physical-server page describes dedicated server rental, shows a visible package marked sold out, says the user can install an operating system and manage the server with a hosting control panel, states in the FAQ that physical-server setup is performed by the company with the selected hardware and software and delivered the same day, and says server orders do not carry a refund guarantee.

These pages support a clear commercial reading. Sentreva is not presenting a hyperscale cloud, a self-service developer platform with public APIs, a multi-region status model or a documented managed-services architecture. It is presenting a Turkish hosting and server provider with familiar small-provider economics: packages, local contact, control-panel language, migration help, hardware/server rental and support. That can be valuable. It also means the buyer's diligence should focus on practical controls rather than brand abstractions. Who can authorize a password reset? How are backups handled?

What happens when an IP reputation problem appears? How are migrations scoped? What is the difference between a Turkey-location package, the routed AS199797 prefix, and the infrastructure used to serve Sentreva's own website?

AS199797 is a routing record, not the whole company

The routing evidence around Sentreva is precise but small. RIPE records identify AS199797 with the AS name sentreva, organization ORG-SIHA22-RIPE and status assigned. The aut-num entity was created on February 17, 2023 and was unchanged in the checked record. It lists imports from AS48678 and AS9121 and exports to those same networks announcing AS199797. The organization entity names Sentreva Internet Hizmetleri Anonim Sirketi, country TR, organization type OTHER, an abuse contact reference, and maintainers including Sentreva-MNT and CIKLET-MNT. The organization entity was created on February 15, 2023 and had a later modification timestamp in May 2026.

Public route evidence then narrows the live picture. RIPEstat's current announced-prefixes data for AS199797 showed one IPv4 prefix, 188.132.151.0/24, visible in the checked window ending July 13, 2026. RIPEstat's routing-status data showed announced IPv4 space of one prefix and 256 addresses, no announced IPv6 space, full IPv4 visibility across the checked RIS peers, zero IPv6 visibility and one observed neighbour. The prefix overview for 188.132.151.0/24 showed the prefix announced with AS199797 as origin.

RIPE's database search for the prefix found an inetnum entity for 188.132.151.0 - 188.132.151.255, netname TR-GEOIPA-PENTECH-20220531, Pentech description, Turkey country code and ASSIGNED PA status; it also found a route object for 188.132.151.0/24 with origin AS199797, created and last modified on December 25, 2023.

That combination is useful because it prevents two opposite mistakes. The first mistake would be to ignore the ASN entirely and treat Sentreva only as a reseller-style website. AS199797 is visible, announced and backed by a route object and valid origin authorization. It is part of the company's public operational record. The second mistake would be to inflate the ASN into proof of independent scale. One visible /24, an upstream dependency and an address block with Pentech context do not establish data-center ownership, broad peering, customer traffic, national coverage, private backbone control or a large operational estate.

RPKI is the strongest positive routing-control signal in the public record. The RIPEstat validation endpoint reported the 188.132.151.0/24 origin AS199797 as valid, with a validating ROA for origin 199797, the same prefix and max length 24. In plain English, the visible route has a public cryptographic authorization that lets networks using route-origin validation see AS199797 as an authorized origin for that exact /24. That is good hygiene. It reduces one class of ambiguity around route origin.

It does not prove that Sentreva's routers are configured well, that upstream filters are perfect, that monitoring is mature, that customer traffic is protected, or that service recovery will be fast.

The AS199797 record should be read as a control surface. It has a registry identity, a policy entity, a visible prefix, an origin authorization, an upstream relationship and a third-party trail across routing tools. Those are the pieces a technical buyer or reviewer can watch over time. Do the RIPE entities remain current? Does the organization maintainer stay aligned with the operator? Does the route object continue to match observed BGP? Does RPKI remain valid? Does a new prefix appear without documentation? Does IPv6 appear later? Does the upstream set diversify or collapse? Does PeeringDB gain a public profile?

Does the company publish a status page or network information page? The value is not a one-time conclusion. It is a baseline for future change detection.

The public website is not proof of the routed network

Sentreva's own website is reachable and carries the commercial story, but its technical delivery is separate from AS199797 in the public evidence. DNS checks for sentreva.com returned Cloudflare A and IPv6 records, Cloudflare nameservers, Google MX records and TXT records including Google site verification plus an SPF policy that includes Mailjet and Google. An HTTP header fetch returned a live HTTPS response through Cloudflare with PHP 8.1 headers, dynamic no-store cache headers, a PHP session cookie, a language cookie and Cloudflare reporting headers.

That tells us something useful: Sentreva's public web presence uses common external delivery and mail-adjacent infrastructure. It does not tell us that the public website is hosted on Sentreva's own AS, on 188.132.151.0/24, in a Sentreva-managed data center, or on the same infrastructure it sells to customers. Cloudflare-fronted websites intentionally hide origin details. Google MX and Mailjet SPF signals say something about email routing and sending policy, not about hosting-package reliability. The public site can be a credible storefront while still being a poor test of the service platform underneath.

This distinction matters because buyers often use the vendor's own website as a crude performance proxy. If the website is fast, they infer the hosting is good. If the website is down, they infer the provider is unreliable. Both shortcuts can mislead. A provider's marketing site may be protected by Cloudflare, served from a different hosting environment, backed by a different mail provider and managed with different operational priorities than customer hosting. Conversely, a provider could have strong customer infrastructure and a simple external website.

The public web test therefore supports only a bounded conclusion: Sentreva maintains a reachable commercial site with account, support and service pages, but the site cannot validate AS199797 or the performance of Sentreva's customer services.

There is also a subtle governance question in the DNS and website records. A hosting provider selling domains and servers has to manage its own public namespace as an asset. The Cloudflare nameserver setup, Google MX records and SPF inclusions show recognizable service dependencies. For customers, that should raise practical questions rather than suspicion. Who controls DNS administrator access? Is domain access protected by multifactor authentication? How are MX changes approved? How are outbound mail providers monitored? How would Sentreva communicate if the website, mail, support portal or Cloudflare configuration were unavailable?

These are ordinary questions for any provider whose own customer communication depends on third-party control points.

The article's boundary is therefore simple. Sentreva's public site is evidence of product categories, pricing signals, corporate contact, account/login paths, support navigation and terms. The site is not evidence of traffic carried over AS199797. AS199797 is evidence of a small routed network identity. The public BGP record is not evidence of the website. A serious assessment keeps those surfaces apart.

Locality is a promise that needs layers

Sentreva's pages repeatedly use Turkey-location language for VPS/VDS and physical servers, and the company contact record places the business in Istanbul. The visible routing records also carry Turkey country context: the RIPE organization is country TR, the prefix inetnum is country TR, and third-party ASN pages classify the AS under Turkey. That is enough to say Sentreva has a Turkish corporate and network-resource identity and sells Turkey-location services.

It is not enough to say precisely where every customer's data will sit, which facility houses a given machine, whether backups leave the country, which subcontractors can access the service, or whether a particular application will meet a customer's data-sovereignty requirements. Locality is not one fact. It has layers. There is legal locality: the company, tax and registry identity. There is commercial locality: Turkish-language support, local phone contact, local billing context and product labels. There is network locality: routes, upstreams, latency paths and country codes in registry records.

There is physical locality: the actual data-center building and hardware. There is operational locality: the people and suppliers who can administer systems. There is data locality: where primary data, replicas, logs and backups are stored.

Sentreva's public record supports some of those layers better than others. The legal and commercial layer is relatively clear. The website and contact page give a Turkish company surface. The product pages sell Turkey-location server options. The network-resource layer is also visible but narrow: AS199797 and 188.132.151.0/24 sit in a Turkish RIPE context, with the address-block record linked to Pentech. The physical and data layers remain less visible. The public pages do not provide a detailed facility list, audited data-residency statement, backup geography, status page, customer architecture notes or contractual data-processing map.

That does not make the locality claim false. It makes it a diligence item. A small business moving a brochure site, a basic mail-enabled domain or a low-risk application may accept a product page and a local support number as enough. A regulated company, a SaaS operator, a public-sector contractor or a business with strict data-handling rules should ask for more: the named facility or facilities, backup location, subcontractor roles, administrative access controls, incident-notice process, domain registrar arrangements, IP assignment terms and exit process. The cost of locality is not just the monthly package price.

It is the cost of proving where the service lives when an auditor, customer or incident demands an answer.

Sentreva's routed /24 also raises the right kind of locality question. If a customer receives an IP address from the 188.132.151.0/24 space, the public route is originated by AS199797 and the underlying inetnum description carries Pentech context. That may be a normal provider/upstream/address assignment arrangement. But the customer should know what that means for abuse handling, reverse DNS, geolocation corrections, routing incidents, reputation cleanup and portability.

If the customer's application depends on country-level IP reputation or a Turkish hosting signal, it should confirm how that signal is created and who can correct it when a database gets it wrong.

Account state is part of the product

The most overlooked technology in small hosting operations is not the server. It is the account record. Sentreva's service agreement makes this unusually visible. Customers must provide accurate information. They must keep a working email address current. Sentreva can use that email for notices. Orders pass through payment and fraud checks. Some services can be automatic, but provisioning can take time. Identity or card documents may be requested. Incorrect details can affect cancellation and refunds. Root passwords and contact details for VDS or dedicated services have to be maintained.

Reseller customers are responsible for their own downstream customers' support.

That means a Sentreva customer's service quality depends partly on a record that the customer controls. A stale email address can become an outage amplifier. A forgotten root password can become a recovery bottleneck. A missing invoice or failed renewal can become a suspension problem. A reseller that does not track its own customers can turn a downstream incident into an upstream account dispute. None of this is unique to Sentreva. What matters is that the terms put the burden plainly enough for the buyer to design around it.

For a small business, the practical controls are simple. Use a shared administrative mailbox rather than an employee's personal address. Store account credentials and recovery details in a managed password system. Assign ownership for domain renewals, hosting renewals and server root credentials. Export invoices and support-ticket history. Record the difference between Sentreva-managed backups, customer-managed backups and no backups. Keep DNS, registrar and hosting access under separate but documented controls. Test account recovery before it is urgent.

For reseller accounts, keep a downstream customer register and a support handoff process.

The same principle applies to Sentreva. A provider's internal account system has to synchronize payment, provisioning, customer identity, service inventory, IP assignment, support history and abuse state. If those records drift, technical competence at the server layer will not save the customer experience. A paid invoice that does not match provisioning can delay setup. A server that exists but is not linked correctly to a ticket can slow support. A route that changes without a matching customer notice can break allowlists. A backup policy that is implied but not recorded can become a dispute after data loss.

The public site hints at the account system through login, account creation, support-ticket and shopping-cart paths. It does not reveal the quality of the back office. That is normal. Public evidence cannot test privileged account workflows without becoming a customer or receiving operator permission. The correct public conclusion is not that Sentreva's account system is weak or strong. It is that account-state discipline is central to the service, and customers should treat it as a shared responsibility rather than a background detail.

Support labour is visible, but not measurable

Sentreva's support surface is visible in several places. The site gives a customer-service phone number and email address. It links to a support system and ticket creation, with ticket creation redirecting through login. It has a knowledge-base page with categories for server/VPS/VDS, domain management, general topics and reseller hosting. During the check, that knowledge base reported no added content and zero-count categories. The service pages repeatedly refer to expert staff and technical support.

This creates a mixed public signal. The company is not hiding contact paths. It has a phone number, email, login, ticket path and support-oriented navigation. At the same time, the visible knowledge base did not contain public articles during the check. For a provider selling hosting, domains and servers, an empty public knowledge base is not a fatal flaw, but it changes the support model. It suggests that many customer questions may depend on direct ticket, phone or email interaction rather than self-service documentation. That can be helpful for local customers who want human support.

It can be costly when repeated operational tasks need consistent written guidance.

Support is labour, not a slogan. A customer who loses access to a server, needs a reverse-DNS change, requests migration help, disputes a renewal, asks for a domain transfer code, needs a backup restored or faces an abuse complaint is relying on people and process. The public record cannot show queue depth, staff coverage, after-hours escalation, first-response time, technical skill, language coverage, retention of ticket history or internal runbooks. It can only show the available doors. Sentreva shows doors, but not measurable support performance.

The support clauses in the agreement make the buyer's role more important. Site migration is described as a best-effort process, not a guarantee that a site will be moved correctly, completely or within a fixed time. The agreement warns that migrations can be difficult or impossible because hosting firms have different configurations. VDS and dedicated servers are not backed up by Sentreva; all data and backup responsibility sits with the customer. Colocation backups are likewise the customer's responsibility. Reseller hosting customers support their own customers, and Sentreva will not support reseller downstream users directly.

Those terms are commercially understandable. They also prevent a buyer from assuming managed-service coverage that may not exist. A VPS package with a low monthly price and one IP address is not the same as a managed high-availability platform. A dedicated server with same-day delivery is not the same as a backup and disaster-recovery service. Free migration help is not the same as guaranteed application compatibility. The support burden has to be priced honestly.

Customers who need hands-on management, backup verification, restore testing, monitoring, patching or incident response should confirm those as explicit services, not infer them from general support language.

Backup responsibility is the sharpest risk boundary

The backup clauses deserve special attention because they mark the difference between recoverable service and unrecoverable disappointment. Sentreva's agreement says VDS and dedicated-server services are not backed up by Sentreva, and that all data and backup responsibility belongs to the customer. For colocation, the customer is likewise responsible for all data and backups. That is one of the clearest pieces of evidence in the public record.

This does not mean Sentreva has no internal backups for any system. It does not speak to every product variation or individually negotiated managed service. It does mean that a customer buying the relevant server categories should not assume provider-managed backups by default. The safe operating assumption is that server data is the customer's responsibility unless a separate service, contract or written order says otherwise. For small businesses, that distinction is often discovered too late. A VPS can feel like a hosted service because someone else owns the hardware.

But if the operating system, application and data live in the customer's server instance, the customer may also own the backup problem.

Backup risk is not just whether a copy exists. It is whether the copy is current, complete, restorable, protected from the same compromise, stored in a different failure domain and understood by someone who can use it under pressure. A cheap backup that has never been restored is not a recovery plan. A backup stored inside the same server is not protection from server loss. A backup controlled by a departing employee is not company resilience. A migration copy is not a long-term backup policy. A control-panel snapshot is not necessarily application-consistent.

If Sentreva is part of a customer's production path, those questions need owners.

The commercial implication is clear. Sentreva may be attractive for customers who want local hosting, low entry prices, Turkish-location servers and direct support. But the price comparison with alternatives should include backup and recovery labour. A self-managed server can be cheap until someone has to patch it, monitor it, back it up, test restores, handle abuse notices and recover it after a credential leak. A more expensive managed service can be cheaper if it includes those controls. Sentreva's public terms make enough of the default boundary visible that buyers can ask the right questions before relying on assumptions.

Routing hygiene is good, but opacity remains

The public routing record gives Sentreva credit for one important thing: the visible origin route is RPKI valid. For a small AS, that is not meaningless. Many routing incidents begin with stale or missing origin authorization, mismatched route objects, abandoned maintainers or unclear upstream filters. Here, the checked public view shows AS199797 originating 188.132.151.0/24 with a valid ROA at max length 24. RIPE, RIPEstat and third-party pages align on the broad facts of the small visible IPv4 footprint.

The opacity is not in the basic route. It is in the operational context around the route. Public evidence does not show what traffic uses the /24. It does not show whether Sentreva assigns addresses from it to hosting customers, server customers, internal systems or future services. It does not show DDoS protection, route filtering policy, BGP session protection, upstream contract terms, status-notice practice, network maintenance windows, geolocation correction process or incident history. It does not show whether AS9121 is a prepared, stale or selectively observed policy relationship.

It does not show why AS48678 is the visible upstream in current third-party views while the RIPE aut-num also lists AS9121.

This is exactly where the difference between public route evidence and operational assurance matters. A valid ROA says the route origin is authorized. It does not say the network is resilient. A one-upstream public view may be sufficient for a small hosting operation, but it is not the same as proven redundant transit. A /24 is enough address space for many hosting uses, but it does not prove scale. A route object created in 2023 can be current, but only if maintainers keep it aligned with reality. A public ASN can make a provider more accountable, but it also creates a record that customers and peers can watch for drift.

For Sentreva, the buyer's technical diligence should be concrete. Ask which services can receive addresses from AS199797. Ask whether customer IP assignments are portable, reassigned, filtered or subject to reputation history. Ask whether reverse DNS is available and how changes are requested. Ask how abuse reports are handled. Ask whether DDoS mitigation is included, optional or upstream-dependent. Ask whether maintenance notices cover routing changes. Ask who updates RIPE entities and ROAs, and how access to those maintainer accounts is protected. Ask whether there is a status page or incident-notice channel.

Ask whether IPv6 is available, planned or unsupported for the service being purchased.

None of those questions implies wrongdoing. They are simply the questions that convert a public route record into operational confidence.

The commercial choice is coordination versus control

The commercial question in the assignment is whether reliability, locality, support and migration costs justify Sentreva's service boundary versus alternatives or self-managed records. The answer depends less on the brand than on the customer's operating maturity.

Sentreva can make sense where the customer wants a familiar Turkish hosting provider, local contact, packaged web hosting, VPS/VDS, dedicated-server rental, domain help, cPanel-style migration support and a provider that can coordinate ordinary hosting tasks. For many small and medium businesses, that is valuable. They do not want to run a router, negotiate transit, maintain control panels, manage server hardware or understand every registry interaction. They want someone reachable who can provision a service, send an invoice, help move a site and answer when something breaks.

The same boundary is risky when the customer silently expects more than the package provides. If a buyer needs guaranteed uptime, documented backup restoration, formal incident response, multi-region redundancy, compliance evidence, managed patching, security monitoring, named account management or traffic engineering, it should not infer those from general hosting language. It should contract for them explicitly or choose a service designed around those controls. The public evidence around Sentreva is not a substitute for an SLA or a technical due-diligence questionnaire.

Self-management is not automatically better. A small business can run its own VPS, DNS, backups and monitoring badly. It can lose root credentials, forget renewals, expose control panels, fail to patch, store backups on the same disk and discover too late that nobody owns recovery. In that comparison, a provider like Sentreva may reduce coordination cost if it supplies enough support and local familiarity. But provider dependency also centralizes certain failures: account lockout, support backlog, billing dispute, upstream outage, unclear backup responsibility or a route problem outside the customer's control.

The sensible comparison therefore asks where each record should live. Domains may be with Sentreva, with another registrar, or separated from hosting to reduce lock-in. DNS may be in Cloudflare or elsewhere. Web hosting may be shared, VPS, dedicated or managed. Backups may be provider-managed, customer-managed or both. Email may use Google, Microsoft, local hosting or a specialized mail provider. IP addressing may be provider-assigned and non-portable. Each choice changes the recovery path. Sentreva's role should be chosen with those paths visible.

Migration is a good example. Sentreva advertises free cPanel-to-cPanel migration help for hosting and server orders, while its terms say migrations are best effort and may fail because providers differ. That is a reasonable boundary, but it means customers should not treat migration as magic. Before moving, they should inventory DNS records, SSL certificates, mailboxes, databases, cron jobs, application versions, PHP extensions, file permissions, backups, domain locks, registrar access and rollback options. The provider can help, but the customer's own records determine whether the move is low drama or a business interruption.

What public evidence cannot establish

There was no direct product test of Sentreva's hosting, VPS/VDS, dedicated-server or support services. A real test would require buying or receiving access to a service, measuring provisioning time, validating control-panel behavior, checking backup options, testing support response, measuring network latency and packet loss, examining IP assignment, reviewing contract terms and performing recovery exercises with permission. None of that is present in the public record.

Public evidence also cannot establish customer counts, revenue, staff size, support backlog, hardware inventory, data-center ownership, upstream contract quality, DDoS capacity, real uptime, restore success, security maturity, patch cadence, vulnerability management, private monitoring or incident history. Third-party ASN pages can show useful routing summaries, but they do not know the customer's experience. A website can show product pages, but product pages are not operations. A service agreement can reveal default responsibilities, but it cannot show how staff handle a difficult ticket.

A valid RPKI record can show origin authorization, but it cannot show whether a customer application will stay online during a maintenance window.

The public record is still useful if used correctly. It establishes the minimum facts a buyer should not have to rediscover from scratch: the company's public service categories, legal contact, setup and support boundaries, backup responsibility for server products, visible AS number, visible prefix, upstream dependency, route-object alignment, RPKI validity and the fact that the public website is Cloudflare-fronted rather than a direct test of the Sentreva AS. It also identifies the risks that need private answers: support response, recovery, locality, monitoring, redundancy and service-specific responsibility.

That is the right way to read a small provider. Not as a blank check, not as a warning label, but as a set of records with different confidence levels.

The next evidence Sentreva could publish

Sentreva could make its public trust surface stronger without exposing sensitive architecture. A short network-information page could state which AS and prefixes are used for which service families, whether IPv6 is available, what upstream dependency exists at a high level, how route-origin authorization is managed and how customers request reverse DNS or abuse handling. A public status page could separate website, client portal, support, DNS, hosting, VPS/VDS, dedicated-server and network incidents.

A backup policy page could distinguish shared hosting backups, VPS backups, dedicated-server backups, managed backups and customer-owned backups in plain language. A migration guide could list what is covered, what is best effort and what customers must prepare. A support guide could define hours, channels, escalation and emergency cases.

Those additions would not need to claim hyperscale capability. They would instead fit Sentreva's apparent market position: a local provider whose value depends on making routine internet operations understandable and recoverable. The evidence gap is not that Sentreva lacks a giant network. The gap is that customers have to infer too much from generic service pages and legal terms when a few operationally precise pages would reduce ambiguity.

The same is true for routing transparency. A small AS with one visible /24 can publish just enough information for customers to know what they are buying. It can state whether customer services normally use that prefix. It can identify the request path for IP reputation and geolocation issues. It can say whether additional upstreams are active, standby, planned or no longer used. It can document RPKI as part of normal network hygiene. It can avoid overpromising redundancy while still showing that records are actively maintained.

This matters because the most damaging failures in small hosting are often not exotic. They are stale records, unclear backups, undocumented migrations, account ownership confusion, missing notices, slow support triage and assumptions about who is responsible for recovery. Publishing clear operational boundaries is not marketing polish. It is a reliability control.

The judgment

Sentreva Internet Hizmetleri should be understood as a Turkish hosting and server provider with a small but real public routing footprint. Its own pages support the service boundary: domains, hosting, VPS/VDS, dedicated servers, software, licensing, local contact, account login, support ticketing, migration help and product packages. Its terms expose important responsibility boundaries around provisioning, account email, migration uncertainty, reseller support and customer-owned backups for VDS, dedicated servers and colocation.

Its RIPE and BGP records show AS199797, one visible IPv4 /24, Pentech-linked prefix context, upstream dependency and valid RPKI origin authorization. Its public website delivery shows Cloudflare and external mail-related dependencies, not direct proof of the Sentreva AS.

That is enough to make Sentreva a monitorable company, not enough to make it a proven large-scale network platform. The correct question is whether its records will remain coherent when customers depend on them: account ownership records, provisioning records, routing records, support records, backup records and locality records. If those stay fresh and customers understand their own responsibilities, Sentreva's model can be a practical local service boundary. If they drift, the same modest complexity can become a source of outage opacity and recovery cost.

For buyers, the practical conclusion is straightforward. Treat Sentreva as a provider whose value is coordination, locality and support, then test those claims through explicit questions before relying on them. Ask what is backed up, what is not, where data sits, which IP space is used, how routes are protected, who handles abuse, how migrations are scoped, how support escalates and what happens when the account owner is unavailable. The public evidence gives a starting map. Operational confidence still has to be earned in the contract, the ticket history, the restore test and the next routing change.