# ServerCake — full tool reference (llms-full.txt) > ServerCake is India's KYC-verified cloud (cloud VMs, managed databases, object > storage), priced in INR with GST invoices and data resident in India. Below is the > full text of every free tool, plus the machine-callable tool API. Short version: https://servercake.in/llms.txt ## Agent-actionable tools These tools are callable over HTTP (GET, JSON, no auth) and registered via WebMCP on each tool page. Full machine-readable spec: https://servercake.in/api/tools/openapi.json - gst_calculate — Add or remove Indian GST for an amount and rate, with the CGST/SGST (intra-state) or IGST (inter-state) split. GET https://servercake.in/api/tools/gst-calculator (amount*: number, rate: number, mode: string, interstate: boolean) Returns: base, gst, total, and cgst/sgst or igst (all INR numbers) plus the rate applied. - reverse_gst_calculate — Given a GST-inclusive total and a rate, find the base price and the GST already included, with the CGST/SGST or IGST split. GET https://servercake.in/api/tools/reverse-gst-calculator (amount*: number, rate: number, interstate: boolean) Returns: base, gst, total, and cgst/sgst or igst (all INR numbers). - subnet_calculate — Compute network address, broadcast, netmask, usable host range and host count for an IPv4 CIDR block. GET https://servercake.in/api/tools/subnet-calculator (cidr*: string) Returns: network, broadcast, netmask, wildcard, firstHost, lastHost, usableHosts, totalHosts, prefix. - sla_downtime — Convert an uptime SLA percentage into the maximum allowed downtime per day, week, month and year. GET https://servercake.in/api/tools/uptime-sla-calculator (uptime*: number) Returns: uptime plus allowed downtime as human strings for daily, weekly, monthly and yearly windows. - base64 — Encode text to Base64 or decode Base64 back to UTF-8 text. GET https://servercake.in/api/tools/base64 (text*: string, mode: string) Returns: result (the encoded or decoded string). - hash_text — Compute the MD5, SHA-1, SHA-256 or SHA-512 hash of a text string (hex). GET https://servercake.in/api/tools/hash-generator (text*: string, algo: string) Returns: algo and hash (lowercase hex digest). - generate_uuid — Generate one or more random RFC 4122 version-4 UUIDs. GET https://servercake.in/api/tools/uuid-generator (count: integer) Returns: uuids (array of v4 UUID strings). - generate_password — Generate a cryptographically-random password with configurable length and character sets. GET https://servercake.in/api/tools/password-generator (length: integer, uppercase: boolean, numbers: boolean, symbols: boolean) Returns: password (the generated string) and length. - dns_lookup — Look up DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA) for a domain. GET https://servercake.in/api/tools/dns (domain*: string, type: string) Returns: the resolved records for the requested type. - dns_propagation — Check how a DNS record has propagated across public resolvers worldwide, including India. GET https://servercake.in/api/tools/dns-propagation (domain*: string, type: string) Returns: per-resolver answers and whether they agree. - ssl_check — Inspect a site's TLS certificate: issuer, subject, validity dates, days-to-expiry, chain and protocols. GET https://servercake.in/api/tools/ssl (domain*: string) Returns: certificate issuer, subject, validFrom, validTo, daysRemaining and chain details. - security_headers — Grade a URL's HTTP security headers (HSTS, CSP, X-Frame-Options and more) and list what is missing. GET https://servercake.in/api/tools/headers (url*: string) Returns: a grade plus present/missing security headers with remediation notes. - email_auth_check — Check a domain's email-authentication records (SPF, DKIM, DMARC) and flag deliverability gaps. GET https://servercake.in/api/tools/email-auth (domain*: string, selector: string) Returns: the SPF, DKIM and DMARC records found and whether each is valid. - port_check — Check whether a TCP port is open and reachable on a host. GET https://servercake.in/api/tools/port (host*: string, port*: integer) Returns: whether the port is open and the connection latency. - blacklist_check — Check whether an IP address or domain is listed on major spam / reputation blacklists (DNSBLs). GET https://servercake.in/api/tools/blacklist (target*: string) Returns: per-blacklist listed/clean status and a summary count. - whois_lookup — Look up domain or IP registration details: registrar, creation/expiry dates and nameservers. GET https://servercake.in/api/tools/whois (domain*: string) Returns: registrar, key dates, status and nameservers. - speed_test — Measure a URL's load time, time-to-first-byte and page size as seen from within India. GET https://servercake.in/api/tools/speed (url*: string) Returns: ttfb, total load time and transferred page size. - get_my_ip — Return the caller's public IP with ISP, ASN and approximate city/country (enriched on ServerCake servers). GET https://servercake.in/api/whats-my-ip Returns: ip, ipVersion, isp, asn, city and country. --- ## Cloud cost in ₹ URL: https://servercake.in/tools/cloud-cost-calculator Free calculator to compare AWS, Azure, GCP, DigitalOcean, Linode and Vultr against ServerCake in Indian rupees, with GST and monthly savings. Key facts: - A cloud VM bill is made of several line items: compute (vCPU and RAM), block storage per GB-month, egress bandwidth per GB, a public IPv4 address billed hourly, and snapshots or backups. - Egress is data leaving the cloud and is metered per GB, while inbound data is usually free, which makes egress a frequently underestimated cost. - The big global clouds (AWS, Azure, Google Cloud, Oracle) quote in US dollars, so an Indian buyer pays the current USD-INR exchange rate plus any card forex markup, then 18 percent GST on top. - Reserved instances or savings plans trade a 1 or 3 year commitment for a large discount, often 30 to 60 percent, but bill whether the VM runs or not. - A fair provider comparison matches vCPU, RAM, disk size and type, region and egress volume before comparing price, since a cheaper quote is often a smaller disk or slower vCPU. ### What a cloud VM actually costs The sticker price of a cloud VM is only the compute part - the vCPU and RAM you rent by the hour. The bill you actually pay adds several line items on top: block storage (the disk, charged per GB-month), bandwidth or egress (data leaving the cloud, often the single most surprising cost), a public IPv4 address (now billed hourly by most providers), snapshots and backups, and load balancers or extra IPs if you use them. Egress is the one that catches teams out. Inbound data is usually free, but data going out to the internet is metered per GB, and a busy app or a large media site can run up more on egress than on the server itself. When you compare providers, price the egress at your real monthly outbound volume, not zero. This calculator adds those components together so you compare a full monthly bill, not just the advertised compute rate. ### Why USD-priced clouds cost more for Indian teams The big global clouds - AWS, Azure, Google Cloud, Oracle - quote in US dollars. For an Indian buyer, three things inflate that number before it hits your account. First, foreign exchange: you pay at the card or bank USD-INR rate on the day, plus any forex markup your card adds. Second, 18% GST is applied on cloud and hosting services in India. Third, egress and inter-region transfer are also dollar-priced, so they carry the same FX and GST load. So a VM advertised at USD 40 a month is not Rs 40 times the spot rate. At roughly Rs {{FX}} to the dollar that is about Rs {{USD40}} of compute, then 18% GST takes it to about Rs {{USD40_GST}}, before you add storage, egress and IPv4 - each of which is also dollar-priced and taxed. Budgeting off the headline USD figure alone understates the real outflow. A provider that bills natively in rupees with GST already on the invoice removes the FX guesswork: ServerCake, for instance, prices in INR and issues a GST invoice, so the amount quoted is the amount debited. ### On-demand vs reserved, and comparing like for like On-demand (pay-as-you-go) is the default: you pay by the hour with no commitment, ideal for spiky or short-lived workloads. Reserved instances or savings plans trade a 1 or 3 year commitment for a large discount - often 30 to 60% off - but you pay whether or not the VM is running, so they only save money on steady, always-on servers. Estimate on-demand first, then check whether a reservation beats it for the hours you will actually run. To compare providers fairly, match the specs before you match the price. Line up the same vCPU count and RAM, the same disk size and type (standard SSD vs high-performance NVMe are priced very differently), the same region (a Mumbai region often costs more than a US one), and the same egress volume. A cheaper-looking quote is often just a smaller disk or a slower vCPU. Only once the specs line up is a rupee-to-rupee comparison meaningful. Glossary: - Compute (vCPU and RAM): Compute is the vCPU and memory rented by the hour and is the sticker price of a cloud VM. It is only one line of the total bill, which also includes storage, egress and other components. - Block storage: Block storage is the VM's disk, charged per GB-month and priced differently by tier, so standard SSD costs less than high-performance NVMe. Its size and type must match when comparing providers. - Egress bandwidth: Egress is data leaving the cloud to the internet, metered per GB, while inbound data is usually free. It is a frequently underestimated cost that can exceed the price of the server itself. - Public IPv4 charge: A public IPv4 address is now billed hourly by most major providers as a separate line item, on top of compute, so a VM's real cost includes the address it is reachable on. - On-demand vs reserved: On-demand pricing is pay-by-the-hour with no commitment, best for spiky workloads. Reserved instances or savings plans give a large discount for a 1 or 3 year commitment but bill whether the VM runs or not. - Like-for-like comparison: A fair provider comparison matches vCPU, RAM, disk size and type, region and egress volume before comparing price, since a cheaper quote is often just a smaller disk or a slower vCPU. FAQ: Q: How accurate are the prices? A: Competitor figures are public list prices for a comparable on-demand Linux VM (roughly 730 hours a month, cheapest common region), excluding data transfer and taxes. They are indicative and change over time, so confirm current prices with each provider. ServerCake's 2 GB price is final; larger sizes are indicative pending launch pricing. Q: Does the comparison include data transfer? A: No. The large clouds bill egress separately, which this calculator does not add, so real-world savings are usually larger. ServerCake includes 1 TB or more of transfer in the price. Q: Which USD to INR rate is used? A: A daily reference rate, shown next to the table and fully editable if the rate has moved. Q: Why compare cloud prices in rupees? A: The global clouds price in dollars, so your bill moves with the exchange rate and often carries an FX markup. ServerCake prices in ₹ with GST invoices, so the number you see is the number you pay. --- ## GST calculator URL: https://servercake.in/tools/gst-calculator Free GST calculator for India. Add or remove GST at 5, 12, 18 or 28%, see the CGST, SGST and IGST split, and get the net and gross amount instantly. Key facts: - To add GST, the tax equals base times rate divided by 100, so 10,000 at 18 percent GST is 1,800 tax and an 11,800 total. - To remove GST from an inclusive amount, base equals total divided by (1 plus rate/100), so 1,180 at 18 percent gives a 1,000 base and 180 GST. - For a supply within the same state, GST splits equally into CGST and SGST, each half the rate, while an inter-state supply is charged as IGST at the full rate. - GST in India has several slabs: 0, 5, 12, 18 and 28 percent, plus 3 percent for specific items, determined by the goods' HSN code or the service's SAC code. - Under the reverse-charge mechanism the recipient, not the supplier, pays GST directly to the government on certain notified supplies. ### How the GST calculation works To add GST, multiply the base amount by the rate and add it back: GST = base x rate / 100, and total = base + GST. So Rs 10,000 at 18% gives Rs 1,800 of GST and an Rs 11,800 total. To remove GST from a price that already includes it (a reverse calculation), divide by 1 plus the rate: base = total / (1 + rate / 100), and the GST is the difference. An Rs 1,180 amount at 18% works back to an Rs 1,000 base and Rs 180 of GST. Within a state the tax splits equally into CGST and SGST, each half the rate. For an inter-state supply the whole amount is charged as IGST at the full rate instead. ### The CGST / SGST / IGST split Most GST calculators only give you the total tax. This one shows the actual split the way it appears on a GST invoice: an intra-state sale shows CGST and SGST at half the rate each, and an inter-state sale shows a single IGST line at the full rate. So Rs 10,000 at 18% within one state shows CGST Rs 900 + SGST Rs 900; the same sale across states shows IGST Rs 1,800. Toggle 'Inter-state (IGST)' to switch between the two. ### Worked examples Add GST, intra-state: Rs 10,000 at 18% gives CGST Rs 900 + SGST Rs 900 = Rs 1,800 GST, total Rs 11,800. Add GST, inter-state: Rs 10,000 at 18% gives IGST Rs 1,800, total Rs 11,800. Remove GST (reverse): an Rs 1,180 GST-inclusive amount at 18% gives a base of Rs 1,000 and Rs 180 GST. Cloud and hosting are usually taxed at 18%, so an Rs 899 plan carries Rs 161.82 GST for an Rs 1,060.82 total. ### Reverse charge and HSN / SAC codes Usually the supplier collects GST, but under the reverse-charge mechanism (RCM) the recipient pays it directly, for example on certain imported services or notified supplies. A standard forward calculation does not apply in those cases, so check whether RCM is relevant to your transaction. The rate itself depends on classification: goods sit under HSN codes and services under SAC codes, and each maps to a 0%, 5%, 12%, 18% or 28% slab. Confirm the correct rate for your HSN or SAC before invoicing. Glossary: - GST (Goods and Services Tax): GST is India's value-added tax on the supply of goods and services, charged at slab rates of 0, 5, 12, 18 and 28 percent (plus 3 percent for specific items), with the rate set by classification. - CGST and SGST: CGST (Central GST) and SGST (State GST) are the two halves of the tax on an intra-state supply. Each is charged at half the total rate, so 18 percent within a state is 9 percent CGST plus 9 percent SGST. - IGST: IGST (Integrated GST) is the single tax charged on an inter-state supply, levied at the full rate instead of being split into CGST and SGST. An 18 percent inter-state supply is 18 percent IGST. - HSN and SAC codes: An HSN code classifies goods and a SAC code classifies services, and each code maps to a specific GST slab. The correct code determines the rate to apply on an invoice. - Reverse charge (RCM): Under the reverse-charge mechanism, the recipient rather than the supplier pays GST directly to the government on certain notified supplies. A normal forward calculation does not apply where RCM is in effect. - Add vs remove GST: Adding GST treats a figure as the base and puts tax on top: GST = base x rate / 100. Removing GST treats a figure as the inclusive total and works backwards: base = total / (1 + rate / 100). FAQ: Q: How do I add or remove GST? A: Enter the amount and pick the rate. 'Add GST' treats your figure as the base and adds tax on top; 'Remove GST' treats it as the gross and works out the tax already included. Q: How do I calculate GST from a total (inclusive) amount? A: Switch to 'Remove GST'. The calculator divides your total by 1 plus the rate to find the base price, then shows the GST already included. For example, Rs 1,180 at 18% gives an Rs 1,000 base and Rs 180 GST. Q: What is the GST calculation formula? A: To add GST: GST = base x rate / 100, and total = base + GST. To remove GST: base = total / (1 + rate / 100), and GST = total - base. Q: When is it CGST and SGST versus IGST? A: For a sale within the same state the tax splits into CGST and SGST, half each. For an inter-state sale the full rate is charged as IGST. This calculator shows both so you can match your invoice. Q: Is GST always 18%? A: No. GST in India has several slabs - 5%, 12%, 18% and 28% (plus 0% and 3% for specific items). The rate depends on the goods' HSN code or the service's SAC code. Many services, including cloud and hosting, are taxed at 18%. Q: What is reverse charge (RCM)? A: Reverse charge means the recipient, not the supplier, pays the GST to the government - for example on certain imported services or notified supplies. Where RCM applies, a normal forward calculation does not; verify whether it applies to your transaction. Q: Which GST rate applies to cloud services? A: Cloud and hosting services are generally taxed at 18% GST in India. ServerCake prices in rupees and issues GST invoices, so the amount you see is the amount you pay. Q: Is anything I enter sent to a server? A: No. The calculator runs in your browser and nothing you type is sent anywhere. --- ## Reverse GST calculator URL: https://servercake.in/tools/reverse-gst-calculator Free reverse GST calculator for India. Enter a GST-inclusive amount and rate to find the base price and the GST already included, with the CGST/SGST/IGST split. Key facts: - A reverse GST calculation starts from a GST-inclusive price and finds both the original base price and the tax it already contains. - The reverse GST formula is base equals total divided by (1 plus rate/100), and GST equals total minus base. - A 1,180 inclusive amount at 18 percent works back to a 1,000 base and 180 GST, and a 1,050 amount at 5 percent gives a 1,000 base and 50 GST. - The extracted GST splits into CGST and SGST at half the rate each for an intra-state supply, or a single IGST line for an inter-state supply. - A reverse GST calculation is used when a quoted or MRP price is GST-inclusive and the pre-tax value is needed for accounting or input-tax-credit records. ### What a reverse GST calculation does A reverse (or 'remove GST') calculation starts from a price that already includes GST and finds two things: the original base price, and how much of the total was tax. It is the opposite of adding GST on top of a base amount. The formula is base = total / (1 + rate / 100), and GST = total - base. For an Rs 1,180 amount at 18%, the base is Rs 1,000 and the GST included is Rs 180. ### Worked examples Rs 1,180 inclusive at 18% gives a base of Rs 1,000 and Rs 180 GST (CGST Rs 90 + SGST Rs 90 intra-state, or IGST Rs 180 inter-state). Rs 1,050 inclusive at 5% gives a base of Rs 1,000 and Rs 50 GST. Rs 1,120 inclusive at 12% gives a base of Rs 1,000 and Rs 120 GST. ### When you need it Use a reverse calculation when a quoted or MRP price is 'GST inclusive' and you need the pre-tax value - for accounting entries, input-tax-credit records, or checking a supplier's invoice. This tool also shows the CGST/SGST or IGST split so it matches how the tax appears on the invoice. Glossary: - Reverse GST calculation: A reverse GST calculation starts from a GST-inclusive price and finds both the original base price and the tax already contained in it. It is the opposite of adding GST on top of a base amount. - GST-inclusive amount: A GST-inclusive amount is a price that already contains the tax, such as an MRP or a quote marked inclusive. The pre-tax base is often needed from it for accounting or input-tax-credit records. - Reverse GST formula: The reverse formula is base = total / (1 + rate / 100), and GST = total minus base. A 1,180 inclusive amount at 18 percent gives a 1,000 base and 180 GST. - CGST / SGST / IGST split: The extracted GST is split into CGST and SGST at half the rate each for an intra-state supply, or shown as a single IGST line at the full rate for an inter-state supply, matching the invoice. - Input tax credit (ITC): Input tax credit lets a registered business offset the GST it paid on purchases against the GST it collects on sales. Extracting the tax from an inclusive price gives the figure recorded for ITC. FAQ: Q: What is reverse GST? A: Reverse GST, also called removing GST, means working backwards from a GST-inclusive price to find the original base amount and the tax it contains, rather than adding GST on top of a base figure. Q: What is the reverse GST formula? A: base = total / (1 + rate / 100), and GST = total - base. For an Rs 1,180 total at 18%, the base is Rs 1,000 and the GST is Rs 180. Q: How do I find the base price from a GST-inclusive amount? A: Enter the inclusive total and the rate; the calculator divides by 1 plus the rate to give the base price, and shows the GST that was already included. Q: Does it show the CGST, SGST and IGST split? A: Yes. It splits the extracted GST into CGST and SGST (half each) for an intra-state supply, or shows a single IGST line for an inter-state supply. Q: Is anything I enter sent to a server? A: No. The calculator runs entirely in your browser; nothing you type is sent anywhere. --- ## Uptime / SLA calculator URL: https://servercake.in/tools/uptime-sla-calculator Free uptime SLA calculator. Turn a 99%, 99.9%, 99.95%, 99.99% or 99.999% SLA into the real downtime allowed per month and per year, in hours, minutes and Key facts: - Allowed downtime equals (1 minus uptime/100) times the length of the period, where a year is 8,760 hours and a 30-day month is 43,200 minutes. - A 99.9 percent uptime SLA (three nines) allows about 8 hours 46 minutes of downtime per year, or roughly 43 minutes per 30-day month. - A 99.99 percent uptime SLA (four nines) allows about 52 minutes 34 seconds of downtime per year, or roughly 4 minutes 19 seconds per month. - Each additional nine of uptime cuts the allowed downtime by roughly ten times, so 99.9 percent to 99.99 percent is a tenfold reduction. - Most SLAs pay out in service credits toward future invoices rather than cash, and typically exclude scheduled maintenance, DDoS attacks and consequential losses. ### What an SLA uptime percentage actually means An availability SLA is a promise about the fraction of time a service is up over a period. 99.9% uptime means the service may be down for at most 0.1% of the period; the allowed downtime is simply (100% - uptime%) times the length of the period. The formula is: allowed downtime = (1 - uptime / 100) x period. A year is 8,760 hours (365 x 24) and a 30-day month is 43,200 minutes, so 99.9% over a year is 0.001 x 8,760 = 8.76 hours, and over a 30-day month is 0.001 x 43,200 = 43.2 minutes. Providers usually quote a monthly figure because SLA credits are calculated per billing month, but buyers often think in yearly terms. This tool shows both so the number you compare against is the one that matters to you. ### The nines: allowed downtime per year and per month 99% (two nines): about 3.65 days a year, or roughly 7 hours 18 minutes a month. This is a weak SLA for anything customer-facing. 99.9% (three nines): about 8 hours 46 minutes a year, or roughly 43 minutes a month. This is the common baseline for shared hosting and many managed services. 99.95%: about 4 hours 23 minutes a year, or roughly 21 minutes 36 seconds a month. A frequent midpoint for business-tier services. 99.99% (four nines): about 52 minutes 34 seconds a year, or roughly 4 minutes 19 seconds a month. Typical for serious cloud infrastructure and needs redundancy to hit. 99.999% (five nines): about 5 minutes 15 seconds a year, or roughly 26 seconds a month. Rare, expensive, and usually requires multi-region failover and automated recovery. Each extra nine cuts the allowed downtime by roughly ten times, so the jump from 99.9% to 99.99% is a tenfold reduction in tolerable outage, not a small tweak. ### Error budgets: the flip side of an SLA The allowed downtime is your error budget. If your target is 99.9% over a month, your error budget is about 43 minutes of downtime; as long as you stay inside it you are meeting the objective, and every outage spends part of it. SRE teams use this budget to balance reliability against shipping speed. If the budget is healthy, you can take more deployment risk; if a bad month has already burned most of it, you freeze risky changes and focus on stability until the budget refills at the start of the next period. Note the difference between an internal SLO (the target your team aims for) and the contractual SLA (the number you are held to). Teams usually set the SLO tighter than the SLA so they have warning before they breach the promise to customers. ### SLA credits: what you actually get for downtime Most SLAs pay out in service credits, not cash and not compensation for your losses. If a provider misses the target, you typically get a percentage of that period's bill back as credit toward future invoices - for example 10% of the monthly fee if uptime falls below 99.9%, more if it falls further. Credits almost never cover consequential loss such as lost sales, missed transactions or reputational damage; SLA terms usually exclude those explicitly. The credit is a penalty on the provider, not insurance for your business. Read the fine print: many SLAs exclude scheduled maintenance windows, third-party or DDoS-driven outages, and problems caused by your own configuration from the downtime count. You usually also have to request the credit within a set window rather than receiving it automatically. Glossary: - SLA (Service Level Agreement): An availability SLA is a contractual promise about the fraction of time a service is up over a period. 99.9 percent uptime means the service may be down for at most 0.1 percent of that period. - Allowed downtime formula: Allowed downtime equals (1 minus uptime/100) times the length of the period. A year is 8,760 hours and a 30-day month is 43,200 minutes, so 99.9 percent over a year allows about 8.76 hours. - The nines: The nines describe availability by the count of leading nines: 99 percent is two nines, 99.9 percent is three nines and 99.99 percent is four nines. Each extra nine cuts allowed downtime roughly tenfold. - Error budget: The error budget is the allowed downtime seen as a spendable amount. Against a 99.9 percent monthly target it is about 43 minutes of outage, and every incident spends part of it until the period resets. - SLO vs SLA: An SLO is the internal reliability target a team aims for, while the SLA is the contractual number it is held to. Teams usually set the SLO tighter than the SLA to get warning before a breach. - Service credits: Service credits are the usual SLA remedy: a percentage of the period's bill refunded toward future invoices if the target is missed. They exclude consequential losses and often exclude scheduled maintenance. FAQ: Q: How much downtime does 99.9% uptime allow? A: 99.9% (three nines) allows about 8 hours 46 minutes of downtime a year, which works out to roughly 43 minutes 12 seconds per 30-day month, about 10 minutes 5 seconds a week, or about 1 minute 26 seconds a day. Q: What does 99.9% uptime mean in hours and minutes? A: It means the service can be unavailable for at most 0.1% of the time. Over a 8,760-hour year that is about 8.76 hours (8 hours 46 minutes); over a 30-day month it is about 43 minutes. Q: What is the difference between 99.9% and 99.99%? A: One extra nine cuts the allowed downtime roughly tenfold. 99.9% permits about 43 minutes of downtime a month, while 99.99% (four nines) permits only about 4 minutes 19 seconds a month, or about 52 minutes 34 seconds a year. Q: How much downtime is five nines (99.999%)? A: 99.999% allows about 5 minutes 15 seconds of downtime per year, or roughly 26 seconds a month. Hitting it usually requires redundancy, multi-region failover and automated recovery, which is why it is rare and expensive. Q: What is the SLA downtime formula? A: Allowed downtime = (1 - uptime / 100) x period. A year is 8,760 hours and a 30-day month is 43,200 minutes, so 99.95% over a year is 0.0005 x 8,760 = 4.38 hours (about 4 hours 23 minutes). Q: What is an error budget? A: An error budget is the allowed downtime seen as a spendable amount. If your target is 99.9% a month, your budget is about 43 minutes of outage; every incident spends part of it, and teams slow down risky changes once most of it is used up. Q: What do I get if a provider misses its SLA? A: Usually service credits, not cash or compensation for your losses. A typical SLA refunds a percentage of that period's bill as credit toward future invoices, and explicitly excludes consequential losses like lost sales or reputational damage. Q: Does the SLA count planned maintenance? A: Often not. Many SLAs exclude scheduled maintenance windows, DDoS attacks and problems caused by your own configuration from the downtime count, so read exactly what 'availability' means in the specific agreement before comparing numbers. Q: What uptime does ServerCake offer? A: ServerCake targets a 99.9% uptime SLA, which is about 43 minutes of allowed downtime a month. Always read the SLA terms for what counts as downtime and how credits are calculated. --- ## What's my IP URL: https://servercake.in/tools/whats-my-ip See your public IP (IPv4 and IPv6), ISP, ASN, city and country, plus the request headers your browser sends. Private: your IP is never sent to a third party. Key facts: - A public IP address is the single address the internet sees for an entire connection, assigned by the ISP to a router rather than to an individual device. - A private IP address such as 192.168.1.5 or 10.0.0.8 is used only inside a local network and never appears on the public internet. - IPv4 is written as four numbers such as 49.37.1.10, while IPv6 is a longer format such as 2401:4900:1c3c::1 created because the world ran out of IPv4 addresses. - An ASN (Autonomous System Number) is a network's unique identifier in the internet's routing system, for example AS55836 for Reliance Jio. - IP geolocation maps IP ranges to a rough area and is accurate to the region or city at best, often pointing to an ISP's hub rather than an exact address. ### Public IP vs private IP The address shown here is your public IP - the single address the internet sees when your connection reaches a website. It is assigned to your router or your ISP, not to your individual device. Inside your home or office, each device has a separate private IP such as 192.168.1.5, 10.0.0.8 or something in the 172.16-172.31 range. These are reused on every network and never appear on the public internet, so a site can never see them. To find a device's private IP, check your operating system's network settings or your router's admin page, not this tool. This is why every device on the same Wi-Fi shows the same public IP here: they all share one address as their traffic leaves the network. ### IPv4, IPv6, ISP and ASN explained IPv4 is the older format written as four numbers like 49.37.x.x. The world ran short of IPv4 addresses, so IPv6 was introduced - a longer format like 2401:4900:xxxx that has room for effectively unlimited addresses. Your connection may have one or both; we show whichever your browser reaches us on. The ISP is the company providing your connection, such as Jio, Airtel or BSNL. The ASN (Autonomous System Number) is the network's unique ID in the internet's routing system - for example AS55836 for Reliance Jio. ISP and ASN both come from public registry data tied to your IP. None of this identifies you personally. It describes the network your traffic exits from, which is often shared by thousands of other users. ### Why your IP changes and why location is approximate Most home connections use a dynamic IP that your ISP can change on a reconnect or over time. A static IP stays fixed and is usually a paid add-on for servers. In India many broadband and mobile connections also sit behind CGNAT (Carrier-Grade NAT), so a whole group of customers shares one public IP - your address can then look the same as a stranger's on the same ISP. The city and country shown come from IP geolocation databases, which map IP ranges to a rough area. This is accurate to the region or city at best, and often points to your ISP's hub rather than your actual street. It is an estimate, not GPS, so do not treat it as a precise location. If you use a VPN or proxy, everything here reflects that server instead - its IP, its ISP and its location - not your real connection. Glossary: - Public IP address: A public IP address is the single address the internet sees for an entire connection, assigned by an ISP to a router rather than to an individual device. It is the address remote servers and this tool observe. - Private IP address: A private IP address, such as 192.168.1.5 or 10.0.0.8, is used only inside a local network and is never routed on the public internet. Multiple devices behind one router share the router's single public IP. - IPv4 vs IPv6: IPv4 is written as four numbers such as 49.37.1.10, while IPv6 uses a longer hexadecimal format such as 2401:4900:1c3c::1. IPv6 was created because the world ran out of IPv4 addresses. - ASN: An ASN (Autonomous System Number) is a network's unique identifier in the internet's routing system, for example AS55836 for Reliance Jio. It maps an IP to the operator that announces it. - IP geolocation: IP geolocation maps IP ranges to a rough geographic area and is accurate to the region or city at best. It often points to an ISP's hub rather than a user's exact address. - CGNAT: Carrier-grade NAT (CGNAT) is a technique where an ISP places many customers behind one shared public IP to conserve IPv4 addresses. Users behind CGNAT cannot host inbound services directly on their public IP. FAQ: Q: Is my IP address shared with a third party? A: No. Most 'what is my IP' tools send your address to an external lookup service. ServerCake enriches it on its own servers using a local database, so your IP is never shared. Q: Why isn't the location exact? A: IP geolocation is approximate and city-level at best. It reflects how your ISP routes traffic, not your precise position, and can be off by a city or more. Q: What is an ASN? A: An Autonomous System Number identifies the network your ISP uses to route traffic on the internet. For example, AS15169 belongs to Google. Q: What is the difference between IPv4 and IPv6? A: IPv4 addresses look like 203.0.113.5; IPv6 are longer and use colons. IPv6 exists because the world ran out of IPv4 addresses. --- ## DNS lookup URL: https://servercake.in/tools/dns-lookup Free online DNS lookup for any domain. Query A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records in one place, with TTLs, from our servers. No sign-up. Key facts: - A DNS lookup translates a human-readable name such as example.com into the records attached to it, most often an IP address but also mail routing and text records. - A DNS A record maps a hostname to an IPv4 address, while an AAAA record maps a hostname to an IPv6 address. - A CNAME record aliases one name to another name and cannot be placed at the zone apex, which is why the root usually needs an A or AAAA record instead. - An MX record names the mail servers that accept email for a domain, each with a priority value where a lower number is preferred. - A DNS TTL (time to live) is the number of seconds a resolver may cache a record before fetching it again, so a record with a TTL of 3600 can be served from cache for up to an hour. ### What a DNS lookup is and how resolution works A DNS lookup asks the Domain Name System to translate a human-readable name like example.com into the data attached to it - most often an IP address, but also mail routing, text records and more. It is the same step your browser or a curl request performs silently before any connection is made. Resolution is recursive and hierarchical. Your resolver first asks a root server, which points to the TLD servers for the suffix (.com, .in, and so on), which point to the domain's authoritative nameservers, which finally return the record. Each answer carries a TTL, and the resolver caches it for that many seconds so the next lookup is instant. This tool queries authoritative or public resolvers directly and returns the current answers per record type, so you see what the internet actually resolves for a domain right now rather than a possibly stale local cache. ### The DNS record types, and what each is for A points a name to an IPv4 address; AAAA points it to an IPv6 address. A single name can have multiple A records for simple round-robin load spreading. CNAME aliases one name to another name (www to the apex, or an apex to a load balancer's hostname). You cannot place a CNAME at the zone apex alongside other records, which is why the root usually needs an A/AAAA record instead. MX names the mail servers that accept email for the domain, each with a priority (lower is preferred). TXT holds free-form text and carries SPF, DKIM and DMARC policies plus domain-verification strings. NS lists the authoritative nameservers for the zone, and SOA (start of authority) holds the zone's primary nameserver, admin contact, serial number and the timers that govern secondary transfers and negative caching. CAA states which certificate authorities may issue certificates for the domain, PTR maps an IP back to a name (reverse DNS), and SRV advertises the host and port of a specific service. ### TTL, caching and why a change is not instant Every record has a TTL (time to live) in seconds. When a resolver fetches a record it keeps the answer for that long, so a record with a TTL of 3600 can be served from cache for up to an hour before the resolver checks again. That is why editing a record does not take effect everywhere at once: resolvers around the world keep serving the old value until their individual copies expire. Lowering the TTL a day before a planned change shortens that window next time. If you are watching a change roll out across many resolvers rather than inspecting one domain's full record set, a propagation checker is the right tool - this lookup shows you the authoritative answer and its TTL in one place. ### Running the same lookup from the command line dig is the reference tool on Linux and macOS. Query a specific type with: dig example.com MX, or all common types with dig example.com ANY (note many resolvers now refuse ANY). Add +short for just the answer, or +trace to follow the delegation from the root down. To bypass your local cache and ask a public resolver directly, target it: dig @1.1.1.1 example.com A. On Windows, nslookup example.com or nslookup -type=mx example.com does the equivalent. When a lookup fails, the resolver's status - NXDOMAIN (no such name) versus SERVFAIL (resolver or zone error) - tells you whether the name is missing or the DNS itself is broken. Glossary: - A record: An A record maps a hostname to a 32-bit IPv4 address. A single name can hold several A records so requests are spread across multiple servers in a simple round-robin. - AAAA record: An AAAA record maps a hostname to a 128-bit IPv6 address. It serves the same role as an A record but for the newer IPv6 address space. - CNAME record: A CNAME record aliases one hostname to another hostname rather than to an IP. It cannot exist at the zone apex alongside other records, so the root of a domain normally uses an A or AAAA record instead. - MX record: An MX record names the mail servers that accept email for a domain, each with a priority value where a lower number is preferred. Multiple MX records provide fallback delivery paths. - SOA record: The start of authority (SOA) record holds a zone's primary nameserver, administrative contact, serial number and the timers that govern secondary transfers and negative caching. Every zone has exactly one SOA record. - TTL: TTL (time to live) is the number of seconds a resolver may cache a record before fetching it again. A record with a TTL of 3600 can be served from cache for up to an hour after it changes. FAQ: Q: What DNS records can I look up? A: A and AAAA (IPv4 and IPv6 addresses), MX (mail servers), TXT (SPF, DKIM, DMARC and verification strings), NS (nameservers), CNAME (aliases), SOA (zone details) and CAA (which certificate authorities may issue certificates). You can query one type or fetch them all in a single lookup. Q: How does a DNS lookup work? A: A resolver walks the hierarchy: it asks a root server, which points to the TLD servers (.com, .in and so on), which point to the domain's authoritative nameservers, which return the record. Each answer includes a TTL, and the resolver caches it for that many seconds before asking again. Q: What is the difference between an A record and a CNAME? A: An A record points a name straight at an IPv4 address, while a CNAME points one name at another name. You cannot place a CNAME at the root (apex) of a domain, which is why the apex normally needs an A or AAAA record instead of a CNAME. Q: What is a DNS TTL? A: TTL (time to live) is how many seconds a resolver may cache a record before fetching it again. A record with a TTL of 3600 can be served from cache for up to an hour. Lowering the TTL before a planned change makes updates propagate faster. Q: Why do my new DNS records not show up yet? A: Resolvers cache records for the length of their TTL, so a change can take minutes to hours to appear everywhere. The authoritative nameservers update immediately, but cached copies elsewhere expire on their own schedule. To watch a change roll out across resolvers worldwide, use a DNS propagation checker. Q: How do I do a DNS lookup from the command line? A: On Linux or macOS use dig, for example dig example.com MX for mail records or dig example.com A for the IPv4 address; add +short for a terse answer. To query a specific resolver use dig @1.1.1.1 example.com. On Windows, use nslookup example.com or nslookup -type=mx example.com. Q: What does DNS lookup failed mean? A: It usually means the resolver could not return an answer. NXDOMAIN means the name does not exist, SERVFAIL means the resolver or the domain's nameservers hit an error, and a timeout means the resolver was unreachable. Checking the record type and the nameservers here helps tell a missing record apart from a broken zone. Q: What is an SOA record? A: The SOA (start of authority) record holds a zone's core settings: the primary nameserver, the admin contact email, a serial number that secondaries use to detect updates, and timers for refresh, retry, expiry and negative (NXDOMAIN) caching. Every zone has exactly one SOA record. Q: Do you store the domains I look up? A: No. The lookup runs on ServerCake's servers and we do not keep a record of the domains you query. --- ## DNS propagation checker URL: https://servercake.in/tools/dns-propagation-checker Free DNS propagation checker. Query public resolvers worldwide, including India, to see if your DNS change is live everywhere. Check A, MX, TXT, CNAME and NS. Key facts: - DNS propagation is the period after a record change during which some resolvers still return the old value and others return the new one until their cached copies expire. - A DNS record change is not pushed across the internet; each recursive resolver holds its cached copy until the record's TTL expires and then refetches from the authoritative nameservers. - The OLD TTL in effect when resolvers last cached a record determines how long the stale value lingers, not the new TTL set at the moment of the change. - DNS changes usually settle within a few minutes to a couple of hours, with 24 to 48 hours as the worst case, and nameserver (NS) changes being the slowest. - A DNS propagation checker sends the same query to public resolvers in different regions, such as Google (8.8.8.8), Cloudflare (1.1.1.1) and Quad9, to show which caches have updated. ### What DNS propagation actually is "DNS propagation" is the informal term for the period after you change a DNS record during which some resolvers still return the old value and others return the new one. Nothing is literally being pushed out across the internet - instead, each recursive resolver simply holds its cached copy of your record until that copy expires, then fetches the fresh value from your authoritative nameservers the next time it is asked. Because resolvers cached your record at different moments and for a duration set by the record's TTL, they expire at different times. That staggered expiry is why a change looks live from one network and stale from another for a while. A DNS propagation checker queries many public resolvers at once so you can watch that rollout complete instead of guessing. The record only ever has one true value at your authoritative nameservers. Propagation is purely about how long cached copies elsewhere take to catch up. ### Why TTL controls how long it takes Every DNS record carries a TTL (time to live) in seconds. When a recursive resolver answers a query, it caches the record and honours that value for up to the full TTL before it will ask your authoritative nameservers again. A record with a TTL of 3600 can therefore be served from a stale cache for up to an hour after you change it; a TTL of 86400 means up to a full day. The critical detail for planned changes: it is the OLD TTL - the value that was in effect when resolvers last cached the record - that governs how long the stale copy lingers, not the new TTL you set at the moment of the change. That is why the professional move is to lower the TTL well in advance of a migration. Some resolvers, and some ISPs, ignore very low TTLs or clamp them to a minimum, so extremely short TTLs do not always behave as advertised. TTL sets the ceiling on cache lifetime, not a guarantee of exact timing. ### How checking from multiple global resolvers works A propagation checker sends the same query - say, the A record for your domain - to a spread of public recursive resolvers in different regions and networks: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9, OpenDNS and regional resolvers, including ones that answer traffic in India. Each resolver returns whatever it currently has cached, so the results form a snapshot of who has updated and who is still serving the old value. This matters because your users do not all resolve through the same servers. Someone on a mobile network in Mumbai and someone on a home connection in London may hit completely different resolver caches. Seeing a mix of old and new answers across regions is normal mid-rollout and simply tells you which caches have not yet expired. For a full record inventory rather than a propagation snapshot, pair this with a plain DNS lookup that returns A, AAAA, MX, TXT, NS, CNAME and SOA in one view. ### Typical propagation windows and how to speed them up In practice most changes settle within a few minutes to a couple of hours. The commonly quoted "24 to 48 hours" is the safe worst case, driven by long TTLs, resolvers that clamp TTLs to a higher floor, and nameserver (NS/registrar) changes, which additionally depend on the TLD registry updating and its own TTLs. Nameserver delegation changes are the slowest kind and are where the 48-hour figure genuinely applies. To speed propagation up you plan ahead: lower the record's TTL to something short (300 seconds is common) at least one old-TTL period before the change - ideally a day or two early - then make the actual change once the low TTL is itself live everywhere. After the change succeeds and you have verified it, raise the TTL back up to reduce query load. You cannot shorten propagation after the fact, only prepare for it beforehand. You can force your own machine to see the new value immediately by flushing its DNS cache or querying an authoritative nameserver directly, but that does not affect anyone else's resolver. Glossary: - Recursive resolver: A recursive resolver is the DNS server that answers a client's query by walking the DNS hierarchy and caching the result. Public examples include Google at 8.8.8.8 and Cloudflare at 1.1.1.1. - Authoritative nameserver: An authoritative nameserver holds the true, current records for a zone and is the source resolvers fetch from when their cache expires. It always reflects a change immediately, even while cached copies elsewhere are still stale. - DNS cache: A DNS cache is the local store where a resolver keeps records it has already fetched, for the length of each record's TTL. Cached copies are why a change is not visible everywhere at once. - Old TTL: The old TTL is the TTL value in effect when a resolver last cached a record, and it governs how long the stale value lingers after a change - not the new TTL set at the moment of the edit. - NS delegation change: An NS delegation change moves a domain to different nameservers and is the slowest kind of DNS change, because it also depends on the TLD registry and its own TTLs updating. This is where the 24 to 48 hour worst case usually applies. - Cache flush: A cache flush clears a machine's local DNS cache so it refetches records instead of serving stale copies. It makes your own device see a new value immediately but has no effect on other people's resolvers. FAQ: Q: What does DNS propagation mean? A: DNS propagation is the period after you change a DNS record during which resolvers around the world gradually stop serving the old cached value and start returning the new one. Nothing is pushed out - each resolver just keeps its cached copy until that copy's TTL expires, then fetches the fresh value from your authoritative nameservers. Propagation is finished when every resolver returns the new value. Q: How long does DNS propagation take? A: Usually a few minutes to a couple of hours for a normal record change, and up to 24 to 48 hours in the worst case. The actual time depends mostly on the record's old TTL and the resolvers involved. Nameserver (NS) changes are the slowest because they also depend on the domain registry and TLD updating, which is where the 48-hour figure most often applies. Q: Why does a record show updated in some places but not others? A: Each recursive resolver caches your record for the length of its TTL, and different resolvers cached it at different moments, so their copies expire at different times. Until a given resolver's cache expires it keeps serving the old value. Seeing a mix of old and new answers across regions is completely normal mid-rollout and simply shows which caches have not yet expired. Q: How can I speed up DNS propagation? A: You cannot speed it up after the change - you prepare beforehand. Lower the record's TTL to a short value like 300 seconds at least one old-TTL period before the change, ideally a day or two early. Once that low TTL is live everywhere, make the actual change; caches will then refresh within minutes. Raise the TTL back afterwards to cut query load. Q: What is TTL and why does it matter for propagation? A: TTL (time to live) is a value in seconds attached to every DNS record that tells resolvers how long they may cache it. A TTL of 3600 lets a resolver serve a stale copy for up to an hour after you change the record. Crucially, it is the OLD TTL in effect before your change that determines how long stale copies linger, not the new TTL - which is why you lower TTL ahead of a planned migration. Q: How does checking DNS from multiple locations work? A: A propagation checker sends the same query to many public recursive resolvers in different regions and networks - such as Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 and regional resolvers, including ones serving India - and shows what each currently returns. Because your users resolve through different servers, this reveals which caches have picked up the new value and which are still serving the old one. Q: How do I check DNS propagation from the command line on Linux? A: Query a specific public resolver with dig, for example "dig @8.8.8.8 example.com A" and "dig @1.1.1.1 example.com A", then compare the answers to the value you set. Run the same query against several resolvers to see the spread. On systems with a local cache, run "sudo systemd-resolve --flush-caches" (or restart the resolver) first so your own machine does not return a stale answer. Q: Why does my DNS change look live on the tool but not on my own computer? A: Your operating system, browser and often your router keep their own DNS caches, separate from the public resolvers the tool queries. Even after public resolvers update, your device can keep serving the old value until its local cache expires. Flush your DNS cache and, if needed, restart the browser or router to see the new value locally. --- ## Subnet / CIDR calculator URL: https://servercake.in/tools/subnet-calculator Free IPv4 and IPv6 subnet calculator. Enter an IP and CIDR prefix to get the network, broadcast, subnet mask, usable host range and host count in your browser. Key facts: - The CIDR prefix is the number of leading bits fixed as the network part of an address, so a /24 fixes the first 24 bits and leaves 8 host bits. - The number of usable hosts on an IPv4 subnet equals 2^(32 - prefix) - 2, subtracting the network address and the broadcast address. - An IPv4 /24 network has 256 total addresses and 254 usable hosts, with a subnet mask of 255.255.255.0. - A /30 subnet has 4 addresses and exactly 2 usable hosts (mask 255.255.255.252), which is the classic mask for a point-to-point link between two routers. - RFC 1918 reserves three private IPv4 ranges that are not routed on the public internet: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. ### What a subnet calculator works out A subnet is a slice of an IP address space defined by a prefix length. Given an address and a CIDR prefix such as 192.168.1.0/24, the calculator derives five things engineers actually need: the subnet mask, the network address, the broadcast address, the range of usable host addresses and the count of usable hosts. The prefix (the number after the slash) is how many leading bits are fixed as the network part. Everything to its right is the host part. A /24 fixes the first 24 bits, leaving 8 host bits; a /26 fixes 26 bits, leaving 6 host bits. More network bits means a smaller subnet. Doing this by hand means converting octets to binary and masking. The calculator does the bit math for you and shows the binary breakdown so the result is easy to sanity-check. ### CIDR notation and the subnet mask CIDR (Classless Inter-Domain Routing) notation writes the mask as a prefix length instead of a dotted-decimal mask. The two are the same information in different form: /24 is 255.255.255.0, /25 is 255.255.255.128, /26 is 255.255.255.192, /30 is 255.255.255.252. To convert a prefix to a mask, set that many high bits to 1 and the rest to 0, then group into four octets. For /26 that is 11111111.11111111.11111111.11000000, which is 255.255.255.192. The value 192 comes from 128 + 64, the two high bits of the last octet. The network address is the IP with all host bits set to 0; the broadcast address is the same block with all host bits set to 1. Any address strictly between those two is assignable to a host. ### How to compute usable hosts For IPv4, the total addresses in a block is 2^(32 - prefix). Two of those are reserved on a normal subnet - the network address and the broadcast address - so the usable host count is 2^(32 - prefix) - 2. Worked example: 192.168.1.0/24. Here 32 - 24 = 8 host bits, so 2^8 = 256 total addresses. Subtract 2 and you get 254 usable hosts. The mask is 255.255.255.0, the network address is 192.168.1.0, the broadcast is 192.168.1.255, and the usable host range runs from 192.168.1.1 to 192.168.1.254. A quick reference: /24 = 256 addresses / 254 hosts, /25 = 128 / 126, /26 = 64 / 62, /27 = 32 / 30, /28 = 16 / 14, /29 = 8 / 6, /30 = 4 / 2. Each step up in prefix halves the block. ### Special cases, IPv6 and private ranges A /30 has 4 addresses and exactly 2 usable hosts, which is the classic mask for a point-to-point link between two routers. A /31 has only 2 addresses and by the old rule leaves 0 usable hosts, but RFC 3021 permits using both addresses on a point-to-point link, so many devices treat a /31 as 2 usable hosts with no broadcast. IPv6 changes the arithmetic. There is no broadcast address and subnets are almost always /64, giving 2^64 addresses per subnet, so the network / broadcast subtraction does not apply the same way. This calculator reports the IPv6 network, the address range and the total address count for the prefix. For lab and internal work, use the RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. These are not routable on the public internet, which is why they are safe defaults for VPCs, home labs and VM networks. Glossary: - CIDR: CIDR (Classless Inter-Domain Routing) is the notation that writes a subnet as an address followed by a slash and a prefix length, such as 192.168.1.0/24. The prefix states how many leading bits are the network part. - Subnet mask: A subnet mask is a 32-bit value whose leading 1 bits mark the network part of an address and trailing 0 bits mark the host part. A /24 prefix corresponds to the mask 255.255.255.0. - Network address: The network address is the first address in a subnet, formed by setting all host bits to zero. It identifies the subnet itself and is not assigned to a host. - Broadcast address: The broadcast address is the last address in an IPv4 subnet, formed by setting all host bits to one. Traffic sent to it reaches every host on the subnet, so it is not assigned to an individual host. - Usable host range: The usable host range is the block of addresses between the network address and the broadcast address that can be assigned to devices. On an IPv4 subnet the count equals 2 raised to the number of host bits, minus 2. - RFC 1918 private ranges: RFC 1918 reserves three IPv4 ranges - 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 - for private networks. Addresses in these ranges are not routed on the public internet. FAQ: Q: What does the CIDR number mean? A: The number after the slash, such as /24, is how many leading bits form the network part of the address. A larger prefix means fewer host bits and therefore a smaller subnet with fewer usable hosts. Q: How many usable hosts are in a /24? A: An IPv4 /24 has 256 total addresses and 254 usable hosts, because the network address (x.x.x.0) and the broadcast address (x.x.x.255) are reserved. The mask is 255.255.255.0. Q: How do I calculate usable hosts from a prefix? A: For IPv4 the formula is 2^(32 - prefix) - 2. The 2^(32 - prefix) part is the total addresses in the block, and you subtract 2 for the network and broadcast addresses. For example a /26 gives 2^6 - 2 = 62 usable hosts. Q: What is a /30 subnet used for? A: A /30 has 4 addresses and exactly 2 usable hosts (mask 255.255.255.252). It is the traditional choice for a point-to-point link between two routers, where you only need one address on each end. Q: Why does a /31 show zero or two usable hosts? A: A /31 has only 2 addresses. By the classic rule both are reserved as network and broadcast, leaving 0 usable hosts. RFC 3021 allows both addresses to be used on a point-to-point link with no broadcast, so modern devices often treat a /31 as 2 usable hosts. Q: How is IPv6 subnetting different? A: IPv6 has no broadcast address, and subnets are almost always /64, which holds 2^64 addresses. Because of that scale, the network and broadcast subtraction used for IPv4 does not apply the same way; the calculator instead reports the network, the address range and the total address count. Q: Which IP ranges are private? A: RFC 1918 reserves three private IPv4 ranges that are not routed on the public internet: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Use these for internal networks, VPCs, home labs and VM subnets. Q: Is my IP or subnet sent to a server? A: No. Every result is computed in your browser using the bit math above, so nothing you enter is sent anywhere or stored. --- ## WHOIS lookup URL: https://servercake.in/tools/whois-lookup Free WHOIS and RDAP lookup for any domain or IP. Read the registrar, creation and expiry dates, nameservers and EPP status codes, plus why owner data is hidden. Key facts: - A WHOIS record lists a domain's sponsoring registrar, its creation, updated and registry expiry dates, its authoritative nameservers and its status codes. - Since GDPR and ICANN's 2018 Temporary Specification, registrars redact registrant personal data by default across most gTLDs while registrar, dates, nameservers and status stay public. - RDAP (Registration Data Access Protocol) is the ICANN-mandated replacement for WHOIS, returning structured JSON over HTTPS instead of unformatted plain text. - Domain status codes are EPP codes, where client-prefixed codes such as clientTransferProhibited are set by the registrar and server-prefixed codes are set by the registry. - The .in domain registry operates under NIXI (National Internet Exchange of India), and its records return the same fields as gTLDs with registrant data redacted the same way. ### What a WHOIS record actually contains A WHOIS record is the registration file a registry or registrar publishes for a domain. The fields you can rely on are the sponsoring registrar and its IANA ID, the registrant contact block (often redacted), and three timestamps: the creation date (when the domain was first registered), the updated date (last change to the record), and the registry expiry date (when it lapses unless renewed). It also lists the authoritative nameservers and one or more domain status codes. Nameservers tell you which DNS provider the domain currently delegates to - useful when a site resolves to the wrong place and you need to confirm whether the domain even points at your host. The status codes tell you what locks and states the registrar and registry have applied. WHOIS answers 'who registered this, through whom, and when does it expire' - not 'what IP does it resolve to right now'. For live resolution use a DNS lookup instead; the two are complementary. ### Why owner details are redacted (GDPR and privacy) If the registrant, admin and tech contacts show as REDACTED FOR PRIVACY, DATASHIELD or a proxy contact, that is expected. Since ICANN's Temporary Specification took effect in 2018 after GDPR, registrars mask personal data of registrants by default across most gTLDs, and many offer free WHOIS privacy that replaces your details with the registrar's proxy. What stays public is non-personal: the registrar, the IANA registrar ID, the creation/updated/expiry dates, the nameservers and the status codes. So you can still tell when a domain expires, who sponsors it and where it is delegated - you just cannot pull a named individual off a public lookup the way you could before 2018. To reach a redacted owner, most registrars provide a web contact form or an anonymised relay email in the record. There is no reliable free tool that reverses proper GDPR redaction; services claiming to reveal owners are usually selling stale pre-2018 or scraped data. ### RDAP - the modern successor to WHOIS WHOIS is a plain-text protocol from the 1980s with no standard format, no authentication and no internationalisation. RDAP (Registration Data Access Protocol) is its ICANN-mandated replacement: it returns structured JSON over HTTPS, supports differentiated access (redacted for the public, fuller for accredited requesters), and is consistent across registries. Since 2025 ICANN has been sunsetting the legacy WHOIS port-43 requirement for gTLD registries in favour of RDAP, so RDAP is now the authoritative source for gTLD registration data. A good lookup tool queries RDAP first and only falls back to legacy WHOIS text where RDAP is not yet offered - typically some ccTLDs. RDAP responses expose the same facts (registrar, dates, nameservers, status) but as machine-readable events and entities, which makes them far easier to parse in scripts and monitoring than scraping free-form WHOIS text. ### Reading domain status (EPP) codes and .in specifics Status codes are EPP (Extensible Provisioning Protocol) codes and split into two families. Client-prefixed codes are set by your registrar - clientTransferProhibited (transfer lock), clientUpdateProhibited, clientDeleteProhibited and clientHold (the domain is set to not resolve). Server-prefixed codes are set by the registry itself, e.g. serverTransferProhibited or pendingDelete. clientTransferProhibited on an active domain is normal and good: it blocks unauthorised transfers, and you clear it yourself before moving a domain. Lifecycle states worth knowing: an expired domain enters a ~30-day renewal grace period, then redemptionPeriod (recoverable at a premium), then pendingDelete before it drops. If you see redemptionPeriod on your own domain, renew immediately. For .in and other India domains, the registry is operated under NIXI (National Internet Exchange of India). WHOIS/RDAP for .in returns the same field shape via NIXI-accredited registrars, with registrant data redacted the same way. India ccTLD records can be rate-limited more aggressively, so a hosted lookup that queries the registry politely is more reliable than repeated command-line whois calls. Glossary: - Registrar: A registrar is the ICANN-accredited company through which a domain is registered and managed, identified by an IANA ID in the record. It is distinct from the registry, which operates the TLD itself. - Registrant: The registrant is the person or organisation that holds the domain registration. Since GDPR and ICANN's 2018 Temporary Specification, registrant personal data is redacted by default across most gTLDs. - RDAP: RDAP (Registration Data Access Protocol) is the ICANN-mandated successor to WHOIS. It returns structured JSON over HTTPS instead of the older tool's unformatted plain text. - EPP status code: An EPP status code describes the locks and states applied to a domain. Client-prefixed codes such as clientTransferProhibited are set by the registrar, while server-prefixed codes are set by the registry. - Registry expiry date: The registry expiry date is the timestamp at which a domain lapses unless it is renewed. WHOIS also records the creation date and the last-updated date alongside it. - NIXI: NIXI (National Internet Exchange of India) operates the .in domain registry. Its WHOIS records return the same fields as gTLDs, with registrant data redacted the same way. FAQ: Q: What does a WHOIS lookup tell me? A: It shows who a domain is registered through and its key dates: the sponsoring registrar, the creation, updated and expiry dates, the nameservers in use, and the domain's EPP status codes. It is the quickest way to check when a domain lapses, which provider controls it and where it is delegated. Personal owner details are usually redacted. Q: Why are the registrant/owner details hidden? A: Since GDPR and ICANN's 2018 Temporary Specification, registrars redact registrant personal data by default across most gTLDs, and many apply free WHOIS privacy that swaps your details for a proxy contact. The registrar, dates, nameservers and status codes stay public; the named person and their address are masked. To reach the owner, use the registrar's contact form or relay email shown in the record. Q: What is RDAP and how is it different from WHOIS? A: RDAP (Registration Data Access Protocol) is the modern replacement for WHOIS. It returns structured JSON over HTTPS instead of unformatted text, supports tiered access, and is standardised across registries. ICANN is sunsetting legacy port-43 WHOIS for gTLDs in favour of RDAP, so RDAP is now the authoritative source. It exposes the same facts but is far easier to parse in scripts and monitoring. Q: What do domain status codes like clientTransferProhibited mean? A: They are EPP status codes. Client-prefixed codes are set by your registrar (clientTransferProhibited locks transfers, clientHold stops the domain resolving, clientUpdateProhibited blocks edits). Server-prefixed codes are set by the registry. clientTransferProhibited on an active domain is normal and protective - it prevents unauthorised transfers, and you clear it yourself before moving a domain. Q: How do I check when a domain expires? A: The registry expiry date is listed in the WHOIS or RDAP result. If it is your own domain and expiry is close, renew well ahead - once it lapses it enters a renewal grace period, then redemptionPeriod (recoverable only at a premium), then pendingDelete before it drops and anyone can register it. Q: Can I WHOIS a .in domain, and is it different? A: Yes. The .in registry operates under NIXI (National Internet Exchange of India), and lookups via NIXI-accredited registrars return the same fields - registrar, dates, nameservers, status - with registrant data redacted the same way as gTLDs. India ccTLD servers can rate-limit repeated queries more aggressively, so a hosted lookup is more reliable than hammering the registry from a command line. Q: Can WHOIS give me the IP address a website uses? A: No. WHOIS returns registration data, not live DNS resolution. It shows the nameservers the domain delegates to, but not the current A/AAAA record. To see the actual IP a domain resolves to, use a DNS lookup, which queries the nameservers directly. Q: Does running this lookup expose my own IP or store my query? A: No. ServerCake runs the WHOIS/RDAP query from its own servers, so the registry sees our infrastructure, not your IP, and we do not store the domains you look up. The registry may still rate-limit heavy automated querying, which is a limit on the source data, not on this tool. --- ## Port checker URL: https://servercake.in/tools/port-checker Free online port checker. Test whether a TCP port is open, closed or filtered on any public host or IP from our servers. Debug firewalls, SSH, web, mail and Key facts: - A TCP port check attempts a connection from an external host to a target host and port and reports whether the port is open, closed or filtered. - An open port means the TCP three-way handshake (SYN, SYN-ACK, ACK) completed and a service is listening, while a closed port means the host replied with a reset and nothing is bound there. - A filtered port means no reply came back before the timeout, indicating a firewall or security group is silently dropping the packet. - Common TCP ports include 22 for SSH, 80 for HTTP, 443 for HTTPS, 25 and 587 for mail, 3306 for MySQL and 5432 for PostgreSQL. - A TCP port check cannot probe UDP services such as DNS on port 53, because UDP is connectionless and has no handshake to observe. ### What this port checker actually tests This tool attempts a TCP connection from our servers on the public internet to the host and port you enter, then reports the result. It answers one precise question: can a machine on the open internet reach this port on this host right now? Because the probe originates from our network and not from your laptop, it tests true external reachability. That is different from running a check on the server itself. A service can be running perfectly and still fail here if it only binds to 127.0.0.1, if a host firewall drops the packet, or if a cloud security group or NAT rule never forwards the port. Testing from outside is the only way to separate 'my service is down' from 'my service is unreachable from the internet'. The result falls into one of three states. Open: the TCP handshake completed and something is listening. Closed: the host answered but rejected the connection (RST), so it is reachable but nothing is listening on that port. Filtered: no answer at all, meaning a firewall or security group is silently dropping the packet, so you cannot even tell if a service is behind it. ### Open vs closed vs filtered, and the TCP handshake TCP opens a connection with a three-way handshake: your side sends SYN, the server replies SYN-ACK, and you finish with ACK. This checker performs exactly that handshake. If SYN-ACK comes back, the port is open. If the server replies with a RST (reset) packet, the port is closed - the host is up and reachable but no process is bound to that port. Filtered is the case that trips people up. If nothing comes back before the timeout, a firewall, security group or ACL is dropping the SYN silently. From outside you cannot distinguish 'no service' from 'service hidden behind a deny rule' - both simply time out. When a port you expect to be open shows filtered, the fix is almost always a firewall or security-group rule, not the application. Note that this tool checks TCP reachability. UDP services (for example DNS on 53 or many game servers) are connectionless and cannot be probed with a handshake, so a lack of TCP response there is expected. ### Common ports and the services behind them Knowing which port maps to which service speeds up debugging. The usual suspects: 21 FTP, 22 SSH, 25 SMTP (server-to-server mail), 587 SMTP submission (mail clients), 53 DNS, 80 HTTP, 443 HTTPS. On the data tier: 3306 MySQL and MariaDB, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB. These database and cache ports should almost never be open to the whole internet - they belong on a private network or behind a firewall that only allows your application servers. If this checker reports 3306, 5432, 6379 or 27017 as open on a public IP, treat it as an incident: bind the service to a private interface or lock the port to known source IPs. For web and mail hosts, seeing 80, 443, 25 and 587 open is normal and expected. Seeing 22 (SSH) open to the world is common but worth tightening - restrict it to your office or VPN range where you can. ### Firewalls, security groups and why we only check public hosts Every reachable port is a door someone can knock on. The right posture is to expose only the ports a service genuinely needs from the internet and drop everything else at the firewall. Use this tool after any firewall, security-group, iptables, ufw or NAT change to confirm from outside that the change did what you intended - open ports are open and, just as important, ports you meant to close no longer answer. This checker only probes publicly routable hosts and IPs. It deliberately refuses private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local and other reserved space. That is an SSRF safeguard: it stops the tool being used to scan networks it should not reach and reflects what a real external client can see. To test a service on your LAN or localhost, run a local check instead (for example nc, telnet or nmap from a machine on that network). If you host with us, the ports open on your VPS are yours to control through the firewall in your panel - open a support ticket if a rule is not behaving as expected. Glossary: - TCP three-way handshake: The TCP three-way handshake opens a connection through three packets: the client sends SYN, the server replies SYN-ACK, and the client finishes with ACK. A port checker performs this handshake to test reachability. - Open port: An open port is one where the handshake completed and a service is listening behind it. The server replied SYN-ACK, confirming both that the host is reachable and that a process is bound to the port. - Closed port: A closed port is one where the host answered with a TCP reset (RST) because nothing is listening there. The host is reachable, but no service is bound to that port. - Filtered port: A filtered port is one where no reply arrives before the timeout, meaning a firewall or security group is silently dropping the packet. From outside, a filtered port is indistinguishable from a hidden service. - Firewall / security group: A firewall or cloud security group is a rule set that permits or blocks traffic to specific ports. A deny rule causes a port that has a running service to appear filtered from the public internet. - UDP: UDP is a connectionless transport protocol with no handshake, used by services such as DNS on port 53. Because there is no handshake to observe, a TCP port checker cannot probe UDP services. FAQ: Q: What does this port checker test? A: It opens a TCP connection from our servers to the host and port you enter and reports whether the port is open, closed or filtered as seen from the public internet. It tests external reachability, not whether a process exists on the box - a service can be running and still show closed or filtered if it binds only to localhost or a firewall blocks it. Q: What is the difference between an open, closed and filtered port? A: Open means the TCP handshake completed and something is listening. Closed means the host answered with a reset, so it is reachable but no service is bound to that port. Filtered means no answer came back at all before the timeout, which indicates a firewall or security group is silently dropping the packet - from outside you cannot tell whether a service is hidden behind it. Q: Why does a port show closed when my service is running? A: The most common causes are that the service is bound to 127.0.0.1 (localhost) instead of 0.0.0.0 or the public interface, or that a host firewall (iptables, ufw), a cloud security group, or a NAT rule is blocking the port from outside. Confirm the listen address with a command like ss -tlnp on the server, then allow the port inbound in your firewall and re-test. Q: Can I check localhost or a LAN address like 192.168.1.10? A: No. This tool only probes publicly routable hosts and refuses private ranges (10.x, 172.16-31.x, 192.168.x), loopback (127.x) and other reserved space. That is an SSRF safeguard and it mirrors what a real external client can reach. To test a service on your own network, run a local check such as nc -vz host port, telnet, or nmap from a machine on that LAN. Q: Which ports should I check most often? A: The usual set is 22 (SSH), 80 and 443 (web), 25 and 587 (mail), 53 (DNS), and 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis) or 27017 (MongoDB) for data services. Database and cache ports should never be open to the whole internet - if any of them answer on a public IP, lock them down to your application servers or a private network. Q: Can this tool check UDP ports? A: No, it checks TCP only. TCP uses a three-way handshake (SYN, SYN-ACK, ACK) that gives a clear open or closed signal. UDP is connectionless, so there is no handshake to observe and an absence of reply cannot be interpreted reliably. For UDP services such as DNS or many game servers, use a UDP-aware tool like nmap -sU from a host that can reach the target. Q: Does an open port mean my server is insecure? A: Not by itself, but every open port is an attack surface someone can probe. The principle is least exposure: publish only the ports a service genuinely needs from the internet and firewall the rest. Restrict admin ports like SSH to a VPN or known IP range, and never leave database ports open to the world. Q: I changed a firewall or security-group rule - how do I confirm it worked? A: Run this checker against the public IP right after the change. Because the probe comes from outside your network, it shows exactly what an external client sees. Confirm the ports you meant to open now answer, and just as importantly that ports you meant to close no longer respond. This external verification catches rules that were applied to the wrong interface or never took effect. --- ## Website speed test from India URL: https://servercake.in/tools/website-speed-test-india Free website speed test from within India. Measure TTFB, total load time and page size as your Indian visitors actually experience them. No sign-up needed. Key facts: - Time to first byte (TTFB) is the gap between a request going out and the first byte of the response arriving, covering DNS, the TCP and TLS handshake, the network round trip and server processing. - A TTFB under 200 ms is fast, 200 to 500 ms is acceptable, and consistently above 500 to 600 ms is worth investigating. - Google treats a TTFB of around 800 ms at the 75th percentile as the point where it starts to harm Largest Contentful Paint. - Network latency is bounded by physical distance, so a round trip from India to a US or European server is inherently longer than to a server in Mumbai, Delhi or Chennai. - Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024, with a good INP being under 200 ms. ### What this test measures This tool requests your URL from a server located inside India and reports three raw numbers: time to first byte (TTFB), total load time, and page size in bytes. It measures how your server responds to an Indian visitor, not how it responds from a US or European probe. TTFB is the gap between the request going out and the first byte of the response coming back. It bundles DNS resolution, the TCP and TLS handshake, the network round trip, and how long your server or application takes to build the response. Total load time is how long the full document took to arrive. Page size is the number of bytes transferred, which matters most on India's mobile networks where bandwidth is uneven. Because the request originates in India, the network round-trip component reflects the real distance between an Indian user and wherever your site is hosted. A site on a US East Coast server can add 200 ms or more of round-trip latency for a Chennai or Delhi visitor before your application does any work at all. ### What counts as a good TTFB As a working guide, a TTFB under 200 ms is fast, 200 to 500 ms is acceptable, and consistently above 500 to 600 ms is worth investigating. Google's own guidance treats around 800 ms at the 75th percentile as the point where TTFB starts to hurt Largest Contentful Paint. A high TTFB has two common causes and it helps to separate them. The first is server processing: slow database queries, no caching, an overloaded VM, or a cold serverless function. The second is distance: even a perfectly fast server adds latency for every kilometre between it and the user. If your server-side processing is quick but TTFB is still high from India, distance is usually the culprit. Run the test a few times. A single reading can be skewed by a cold cache or a one-off network blip; three or four runs give you a truer picture of the typical response. ### Why server location matters for Indian visitors Network latency is bounded by the speed of light and the path packets take through undersea cables and peering points. A round trip from India to a server in Virginia or Frankfurt is physically longer than a round trip to a server in Mumbai, and no amount of application tuning removes that floor. For Indian audiences, hosting in an India region (Mumbai, Delhi or Chennai points of presence) or putting a CDN edge inside India cuts the round trip dramatically. A CDN caches static assets like images, CSS and JavaScript at an edge near the user, so those bytes travel a short distance even if your origin server sits abroad. Dynamic responses still hit the origin, so for API-heavy or logged-in pages, the origin's location keeps mattering. ServerCake runs infrastructure inside India with rupee billing, so for an India-first audience the origin round trip is short by default. That is one honest lever among several - CDN, caching and page weight are the others. ### Quick server test vs a full Lighthouse audit This is a fast server-response test, not a full front-end audit. It tells you how quickly bytes leave your server and reach India, which is the foundation everything else sits on. It does not render the page, run JavaScript, or measure how the layout paints in a browser. For the rendering side you need Core Web Vitals, which Google measures on real visits: Largest Contentful Paint (LCP, how fast the main content appears, good is under 2.5 s), Interaction to Next Paint (INP, how responsive the page feels to input, good is under 200 ms), and Cumulative Layout Shift (CLS, how much the layout jumps, good is under 0.1). Note that INP replaced First Input Delay as a Core Web Vital in March 2024. A Lighthouse or PageSpeed Insights audit covers that rendering layer - render-blocking resources, image formats, unused JavaScript, and lab-simulated LCP. Use this tool first to confirm the server responds quickly from India, then run Lighthouse to fix what happens after the bytes arrive. A slow TTFB will drag down LCP no matter how well the front end is built, so it is the right thing to check first. Glossary: - TTFB: Time to first byte (TTFB) is the gap between a request going out and the first byte of the response arriving. It bundles DNS, the TCP and TLS handshake, the network round trip and server processing time. - Network latency: Network latency is the time a packet takes to travel between two points, bounded by physical distance and the path through undersea cables and peering points. A round trip from India to a US or European server is inherently longer than to a server in Mumbai. - Page weight: Page weight is the total number of bytes a page transfers, including HTML, images, fonts, CSS and JavaScript. Heavy pages load slowly on India's uneven mobile networks, so trimming assets is often the biggest speed win. - Largest Contentful Paint: Largest Contentful Paint (LCP) is a Core Web Vital that measures how quickly a page's main content appears, with under 2.5 seconds considered good. A slow TTFB drags LCP down regardless of front-end tuning. - Interaction to Next Paint: Interaction to Next Paint (INP) is a Core Web Vital measuring how responsive a page feels to user input, with under 200 ms considered good. It replaced First Input Delay as a Core Web Vital in March 2024. - CDN edge: A CDN edge is a cache near the user that serves static assets like images, CSS and JavaScript over a short distance. Placing an edge inside India cuts the round trip for Indian visitors, though dynamic responses still reach the origin. FAQ: Q: Why test speed from India specifically? A: If your audience is in India but your site is hosted far away, distance adds network latency that global test tools running from the US or Europe never show you. This test measures load time from a server inside India, so you see what your Indian visitors actually get. Q: What is TTFB and why does it matter? A: Time to first byte is how long the server takes to start responding after a request, covering DNS, the TLS handshake, the network round trip and your server's processing time. A high TTFB delays everything that follows, so it drags down the whole page including your Largest Contentful Paint score. Q: What is a good TTFB? A: As a rule of thumb, under 200 ms is fast, 200 to 500 ms is acceptable, and consistently above 500 to 600 ms is worth investigating. Google treats around 800 ms at the 75th percentile as the point where TTFB starts to harm your Core Web Vitals. Q: What do the total time and page size tell me? A: Total time is how long the page took to finish loading, and page size is how many bytes it transferred. Large pages are slow on India's mobile networks, so trimming images, fonts and scripts often gives the biggest speed win. Q: How does server location affect speed for Indian users? A: Network latency is bounded by physical distance, so a round trip from India to a US or European server is inherently longer than to a server in Mumbai, Delhi or Chennai. Hosting in an India region or using a CDN with an Indian edge cuts that round trip and lowers TTFB for Indian visitors. Q: How is this different from Lighthouse or PageSpeed Insights? A: This is a quick server-response test: it measures how fast bytes leave your server and reach India. Lighthouse and PageSpeed Insights render the page and measure the front-end Core Web Vitals - LCP, INP and CLS. Use this tool first to confirm the server is fast from India, then run Lighthouse to fix what happens after the bytes arrive. Q: Does this measure Core Web Vitals like LCP, INP and CLS? A: No. This test reports server-response metrics (TTFB, total load time and page size), not the rendering metrics. LCP, INP and CLS are measured in a real browser on actual visits, so use a field-data tool like PageSpeed Insights or Chrome's CrUX report for those. A slow TTFB here, though, will still hurt your LCP. Q: My site is slow from India. What should I do? A: First separate the two causes: run the test a few times to see if TTFB is high because of slow server processing (add caching, tune queries) or because of distance. If distance is the issue, host closer to your users or add an Indian CDN edge. ServerCake runs in India with rupee billing, so for an India-first audience the origin round trip is short by default. --- ## SSL / TLS checker URL: https://servercake.in/tools/ssl-checker Check any SSL/TLS certificate: the leaf, intermediate and root chain, issuer, SAN, validity and days to expiry, plus expired or mismatched certs. Key facts: - An SSL/TLS certificate binds a public key to a set of hostnames and proves that a Certificate Authority verified control of those hostnames before signing it. - The certificate chain flows from a leaf certificate up through one or more intermediate CA certificates to a self-signed root that lives in the client's trust store. - A server must send its leaf certificate plus every intermediate but not the root, and a missing intermediate is the most common misconfiguration - it passes in Chrome yet fails in curl, Java, Python requests and mobile apps. - Modern clients match the visited hostname only against the Subject Alternative Name (SAN) extension and ignore the legacy Common Name, so a hostname missing from the SAN triggers NET::ERR_CERT_COMMON_NAME_INVALID. - Let's Encrypt and most modern free CAs issue 90-day certificates, and TLS 1.3 and 1.2 should be enabled while TLS 1.0 and 1.1 are deprecated and should be disabled. ### What an SSL/TLS certificate actually proves An SSL/TLS certificate binds a public key to a set of hostnames and proves that a Certificate Authority (CA) verified control of those hostnames before signing. It does two jobs at once: it lets the client encrypt the session with the server's public key, and it authenticates that you are talking to the real owner of the domain and not a machine-in-the-middle. The certificate does not prove the business behind the site is trustworthy, only that whoever holds the matching private key controlled the domain at issuance time. Domain Validated (DV) certs, which Let's Encrypt and most free issuers hand out, confirm domain control only. Organisation Validated (OV) and Extended Validation (EV) certs add vetted company details to the Subject field but are otherwise the same TLS underneath. This checker reads the live certificate served on the TLS handshake, so it reflects exactly what browsers and API clients see, not what is sitting in a file on disk. ### The chain of trust: leaf, intermediate and root Trust flows top-down. A root CA certificate lives in the browser or OS trust store and is self-signed. Roots almost never sign server certificates directly; instead they sign one or more intermediate CA certificates, and those intermediates sign your leaf (end-entity) certificate. A client trusts your site only if it can build an unbroken path from your leaf up to a root it already trusts. Your server is responsible for sending the leaf plus every intermediate in the chain. It must not send the root, since the client already has it. If an intermediate is missing, the client cannot complete the path and rejects the connection, even though the leaf itself is perfectly valid. This is the single most common misconfiguration and the reason a cert can pass in Chrome (which sometimes caches or fetches intermediates) yet fail in curl, Java, Python requests or a mobile app. The checker walks the chain it receives, shows each certificate's issuer and subject, and flags an incomplete chain so you can fix the fullchain file your server sends. ### Reading issuer, subject, validity and SAN Issuer is the CA that signed the certificate; Subject is who it was issued to. On modern certificates the Subject Common Name (CN) is legacy and effectively ignored - browsers match the hostname only against the Subject Alternative Name (SAN) extension. If the hostname you visit is not listed in the SAN, you get NET::ERR_CERT_COMMON_NAME_INVALID or a name-mismatch error, regardless of what the CN says. Validity is the notBefore and notAfter window in UTC. A certificate is untrusted before notBefore (clock-skew problems on the server look like this) and after notAfter (expired). Wildcards such as *.example.com cover one label only, so they match api.example.com but not deep.api.example.com and never the bare example.com unless that is listed separately. You can read the same fields from the command line with: openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -issuer -subject -dates -ext subjectAltName. The -servername flag is required because virtually all hosts use SNI to serve the right certificate per hostname on a shared IP. ### Expiry, TLS versions and staying green Let's Encrypt and most modern free CAs issue 90-day certificates by design, on the assumption that renewal is automated. Certbot, acme.sh, Caddy and most panels renew at around the 30-day-remaining mark. The failure mode to watch is a renewal cron that silently breaks - the cert quietly ages out and the site goes dark. Monitor days-to-expiry rather than trusting that automation is running, and alert well before zero. On the protocol side, prefer TLS 1.3 and keep TLS 1.2 for older clients; TLS 1.0 and 1.1 are deprecated and should be disabled. TLS 1.3 drops the round trip and removes weak cipher suites, so it is both faster and safer. The certificate itself is version-agnostic - the same cert works over 1.2 and 1.3 - so a protocol problem is a server-config problem, not a certificate problem. The industry is moving toward much shorter lifetimes (45 days from 2029 under the CA/Browser Forum plan), which makes automated renewal and expiry monitoring non-optional rather than nice-to-have. Glossary: - Certificate chain: The ordered path of certificates a client follows to establish trust, running from the leaf up through one or more intermediate CA certificates to a trusted root. A client accepts the connection only if it can build an unbroken path from the leaf to a root it already trusts. - Leaf (end-entity) certificate: The certificate issued to the actual server, binding its public key to the hostnames it serves. It is signed by an intermediate CA rather than directly by a root, and is the certificate presented first in the TLS handshake. - Intermediate CA certificate: A certificate signed by a root CA that in turn signs leaf certificates, forming the middle of the chain of trust. The server must send every intermediate along with the leaf, since a missing intermediate is the most common cause of a chain that passes in Chrome but fails in curl, Java or mobile apps. - Root CA certificate: A self-signed certificate held in the browser or operating system trust store that anchors the chain of trust. Roots almost never sign server certificates directly and are not sent by the server, because the client already holds them. - Subject Alternative Name (SAN): The certificate extension listing every hostname the certificate is valid for. Modern clients match the visited hostname only against the SAN and ignore the legacy Common Name, so a hostname absent from the SAN triggers a name-mismatch error such as NET::ERR_CERT_COMMON_NAME_INVALID. - TLS handshake: The negotiation at the start of a connection where the server presents its certificate and the two sides agree on keys and a protocol version to encrypt the session. TLS 1.3 and 1.2 are the versions to offer, while TLS 1.0 and 1.1 are deprecated and should be disabled. FAQ: Q: Why does my certificate work in Chrome but fail with curl or a mobile app? A: Almost always an incomplete chain. Browsers can cache or fetch missing intermediate certificates using the AIA extension, but curl, Java, Python requests and mobile apps do not. Fix it by serving the full chain (leaf plus all intermediates, in order) - point your server at the fullchain.pem file rather than the bare certificate. Q: What does NET::ERR_CERT_COMMON_NAME_INVALID mean? A: The hostname you visited is not listed in the certificate's Subject Alternative Name (SAN) extension. Modern clients ignore the legacy Common Name and match only against the SAN, so the fix is to reissue the certificate with every hostname you serve included in the SAN, or use a wildcard that covers them. Q: Why is my Let's Encrypt certificate expired when renewal was set up? A: The renewal job silently stopped. Common causes: the certbot systemd timer or cron was disabled, a pre/post hook fails, port 80 got firewalled so the HTTP-01 challenge cannot validate, or the DNS changed. Run your renew command with --dry-run to reproduce the failure, and monitor days-to-expiry so a broken renewal alerts you before the cert lapses rather than after. Q: Is a self-signed certificate a problem? A: For anything public-facing, yes - a self-signed certificate is not signed by a trusted CA, so browsers and clients reject it with an untrusted-issuer error. Self-signed certs are fine for local development or internal services where you control every client and can pin or install the cert, but for a real domain use a CA-issued certificate such as a free Let's Encrypt one. Q: How do I check a certificate's expiry from the command line? A: Run: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates. This prints notBefore and notAfter. The -servername flag sends SNI so you get the right certificate on a shared IP. This checker does the same handshake and shows days remaining directly. Q: What is the difference between the certificate and the TLS version? A: The certificate proves identity and carries the public key; the TLS version (1.2, 1.3) is the protocol used to negotiate the encrypted session. The same certificate works across TLS versions, so a handshake failure or a weak-protocol warning is a server configuration issue, not a certificate one. Aim to offer TLS 1.3 and 1.2 only, and disable the deprecated 1.0 and 1.1. Q: Does a wildcard certificate cover subdomains of subdomains? A: No. A wildcard like *.example.com covers exactly one label, so it matches api.example.com and www.example.com but not deep.api.example.com, and it does not cover the bare example.com unless that apex name is listed separately in the SAN. For multiple levels you need a certificate that lists each pattern or a multi-domain (SAN) certificate. Q: How many days before expiry should I renew, and how do I get warned? A: Renew with a comfortable buffer - most automated tools renew at 30 days remaining, and you should alert if a cert drops below roughly 14 days so a failed renewal is caught in time. Rather than trusting the cron is running, monitor days-to-expiry per host. ServerCake can watch your certificates and email you before one lapses. --- ## HTTP security headers URL: https://servercake.in/tools/security-headers-checker Free HTTP security headers checker. Scan any URL and grade it A to F on HSTS, Content-Security-Policy, X-Frame-Options and more, with sample values to fix each Key facts: - HTTP security headers are response headers that instruct the browser to enforce defences such as forcing HTTPS, blocking framing, refusing MIME sniffing and constraining which scripts a page may load. - Strict-Transport-Security (HSTS) forces the browser to use HTTPS and reject downgrades, with a strong value being max-age=31536000; includeSubDomains; preload. - Content-Security-Policy is the strongest defence against cross-site scripting because it whitelists exactly which origins may serve scripts, styles and other resources and blocks everything else. - X-Content-Type-Options: nosniff stops the browser from second-guessing the declared Content-Type, and X-Frame-Options: DENY (or the modern CSP frame-ancestors 'none') prevents clickjacking by blocking framing. - Permissions-Policy switches off powerful browser features a site does not use, such as camera, microphone, geolocation and payment, so an injected script cannot silently reach for them. ### What HTTP security headers do HTTP security headers are response headers a server sends alongside a page that tell the browser to enforce extra defences: force HTTPS, block framing, refuse to guess content types, and constrain what scripts and resources a page may load. They cost nothing to send and shut down whole classes of attack - protocol downgrade, clickjacking, MIME sniffing and cross-site scripting - at the browser rather than in your application code. This checker fetches the response headers for a URL, reports which protective headers are present and sensibly configured, and grades the result A to F. Missing high-impact headers such as Strict-Transport-Security and Content-Security-Policy pull the grade down the most, because they defend against the most damaging attacks. The headers are defence in depth, not a substitute for fixing the underlying bug. A good CSP makes an injected script fail to execute, but you still patch the injection point. Treat the grade as a floor to clear, not a finish line. ### HSTS, X-Content-Type-Options, X-Frame-Options and Referrer-Policy Strict-Transport-Security (HSTS) forces the browser to use HTTPS for your domain and refuses any plain-HTTP or invalid-certificate connection, which kills SSL-stripping downgrade attacks. A solid value is 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' - one year, all subdomains, and eligible for the browser preload list. Only enable it once HTTPS works on every subdomain, because it is sticky; start with a short max-age if you are unsure. X-Content-Type-Options: nosniff stops the browser from second-guessing the declared Content-Type and executing, say, an uploaded text file as JavaScript. It is a one-line header with no downside - always set 'X-Content-Type-Options: nosniff'. X-Frame-Options: DENY (or SAMEORIGIN) stops other sites embedding your pages in a frame, which is the mechanism behind clickjacking. The modern replacement is the CSP directive 'frame-ancestors', which is more flexible and honoured by current browsers; set 'frame-ancestors 'none'' in your CSP and keep X-Frame-Options for older clients. Referrer-Policy controls how much of the referring URL is sent when a user clicks away, so you do not leak paths or query strings (tokens, IDs) to third parties. A sensible default is 'Referrer-Policy: strict-origin-when-cross-origin', which sends the full URL within your own origin but only the origin to other sites, and nothing when downgrading HTTPS to HTTP. ### Content-Security-Policy: the strongest XSS defence Content-Security-Policy (CSP) is the single most effective header against cross-site scripting because it whitelists exactly which origins may serve scripts, styles, images, frames and connections, and blocks everything else - so even an injected script fails to run unless it comes from an approved source. Nothing else in this list contains XSS as tightly. It is also the hardest header to get right. A real policy has many directives, breaks inline scripts and third-party widgets if written carelessly, and a too-loose value (like 'unsafe-inline' or a wildcard) quietly defeats the point. A strong modern approach is nonce- or hash-based: 'Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-'; object-src 'none'; base-uri 'none'; frame-ancestors 'none''. The 'nonce' changes per response and only scripts carrying it execute. Roll CSP out in stages. Deploy 'Content-Security-Policy-Report-Only' first with a 'report-uri' or 'report-to' endpoint, watch what would have been blocked in real traffic, tighten until the reports are clean, then switch to the enforcing header. Rushing straight to enforce mode usually breaks the site. ### Permissions-Policy and putting it together Permissions-Policy (formerly Feature-Policy) lets you switch off powerful browser features your site does not use - camera, microphone, geolocation, USB, payment - so a compromised or injected script cannot silently reach for them. If your app needs none of them, a tight value is 'Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()', where the empty allowlist means 'no origin, including self'. Set these headers once at the edge or in your server config so they apply to every response: an Nginx 'add_header', an Apache 'Header set', or middleware in your app framework. Send them on error pages and redirects too, not just 200s. Re-scan after any deploy - a config change or a new third-party embed can silently regress a header or force you to loosen your CSP. If your certificate or TLS setup is the weak link rather than the headers, confirm HTTPS is healthy first with the SSL checker; HSTS is only safe to enable once that is solid. Glossary: - Strict-Transport-Security (HSTS): A response header that forces the browser to use HTTPS for a domain and reject plain-HTTP or invalid-certificate connections, defeating SSL-stripping downgrade attacks. A strong value is max-age=31536000; includeSubDomains; preload, and it should be enabled only after HTTPS works on every subdomain. - Content-Security-Policy (CSP): A header that whitelists exactly which origins may serve scripts, styles and other resources, blocking everything else, which makes it the strongest defence against cross-site scripting. Roll it out first in Content-Security-Policy-Report-Only mode before switching to enforcement. - X-Frame-Options: A header (DENY or SAMEORIGIN) that stops other sites embedding a page in a frame, the mechanism behind clickjacking. The modern, more flexible replacement is the CSP frame-ancestors directive, though X-Frame-Options is kept for older clients. - X-Content-Type-Options: A header whose nosniff value stops the browser second-guessing the declared Content-Type and, for example, executing an uploaded text file as JavaScript. It is a one-line header with no downside and should always be set. - Referrer-Policy: A header controlling how much of the referring URL is sent when a user navigates away, preventing leakage of paths or query strings such as tokens to third parties. A sensible default is strict-origin-when-cross-origin. - Permissions-Policy: A header (formerly Feature-Policy) that switches off powerful browser features a site does not use, such as camera, microphone, geolocation and payment, so an injected script cannot silently reach for them. An empty allowlist like camera=() denies the feature to every origin including the site itself. FAQ: Q: Which security headers do you check? A: The key HTTP response headers: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Each defends against a specific class of attack - downgrade, XSS, clickjacking, MIME sniffing and referrer leakage - and the checker reports which are present and sensibly set. Q: How is the A to F grade worked out? A: The scan scores which protective headers are present and correctly configured, then maps that to a letter grade. Missing high-impact headers like HSTS and Content-Security-Policy pull the grade down the most, while a weak value - such as a CSP using unsafe-inline - counts as present but not effective. Q: What is HSTS and what value should I use? A: Strict-Transport-Security tells browsers to only ever connect over HTTPS and reject downgrades. A strong value is 'max-age=31536000; includeSubDomains; preload' (one year, all subdomains, preload-eligible). Enable it only after HTTPS works on every subdomain, because it is sticky; start with a short max-age if you are unsure, then raise it. Q: Why is Content-Security-Policy the most important header? A: CSP whitelists exactly which origins may load scripts, styles and other resources and blocks everything else, so an injected script simply does not run unless it comes from an approved source. That makes it the strongest defence against cross-site scripting - no other header contains XSS as tightly. Q: Why is CSP the hardest header to get right? A: A real policy has many directives and can break inline scripts or third-party widgets, while a too-loose value like unsafe-inline or a wildcard quietly defeats the point. The safe path is to deploy Content-Security-Policy-Report-Only with a reporting endpoint, watch what would break in real traffic, tighten until reports are clean, then switch to enforce mode. Q: What is the difference between X-Frame-Options and CSP frame-ancestors? A: Both stop your pages being embedded in a frame to prevent clickjacking. X-Frame-Options (DENY or SAMEORIGIN) is the older header; the CSP directive frame-ancestors is the modern, more flexible replacement honoured by current browsers. Set frame-ancestors 'none' in your CSP and keep X-Frame-Options as well for older clients. Q: Where do I set these headers? A: Set them once at the edge or in server config so they apply to every response - an Nginx add_header, an Apache Header set, a CDN rule, or middleware in your framework. Make sure they also go out on redirects and error pages, not only on 200 responses. Q: Are security headers enough to secure my site? A: No. They are an important layer of defence in depth but not the whole job. Pair them with a valid TLS certificate (check it with the SSL checker), keep your server and dependencies patched, and fix the underlying bugs - a header makes exploitation harder, it does not remove the vulnerability. Q: Is the URL I scan stored? A: No. The scan runs on ServerCake's servers to fetch the target's response headers, and we do not keep a record of the URLs you check. --- ## SPF / DKIM / DMARC checker URL: https://servercake.in/tools/spf-dkim-dmarc-checker Free SPF, DKIM and DMARC checker for any domain. Read your v=spf1 TXT record, DKIM selector key and _dmarc policy, and fix the gaps that send mail to spam. Key facts: - SPF (Sender Policy Framework) is a DNS TXT record at the domain root that begins with v=spf1, lists the servers authorised to send mail for the domain, and ends with an all mechanism. - DKIM (DomainKeys Identified Mail) publishes a public key in DNS at selector._domainkey.yourdomain.com so the receiver can verify a cryptographic signature the sending server added to each message. - DMARC is a TXT record at _dmarc.yourdomain.com that sets the policy (p=none, p=quarantine or p=reject) for mail failing SPF or DKIM and can send aggregate reports via a rua address. - DMARC alignment requires the domain that passed SPF or DKIM to match the visible From header domain, and a message passes DMARC when at least one of SPF or DKIM both passes and aligns. - SPF evaluation is capped at 10 DNS lookups counting every include, a, mx, ptr and exists mechanism, and exceeding the limit produces a permerror treated as a failure. ### What SPF, DKIM and DMARC each do SPF (Sender Policy Framework) is a TXT record at your domain root that lists which servers are allowed to send mail as you. It always begins with v=spf1 and ends with an all mechanism. Receivers check the sending IP against this list. DKIM (DomainKeys Identified Mail) publishes a public key in DNS at selector._domainkey.yourdomain.com. Your outbound server signs each message with the matching private key, and the receiver verifies the signature to confirm the message was not altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain.com. It tells receivers what to do when SPF or DKIM fails, and it can send you aggregate reports so you can see who is sending mail in your name. ### How the three work together (and alignment) SPF and DKIM each produce a pass or fail, but on their own they do not decide the fate of a message. DMARC is the layer that ties them together and enforces a policy. DMARC also requires alignment: the domain that passed SPF or DKIM must match the domain in the visible From header. SPF alignment compares the From domain to the Return-Path (envelope sender) domain; DKIM alignment compares it to the d= tag in the signature. A message passes DMARC when at least one of SPF or DKIM both passes and aligns. This is why forwarding often breaks SPF but DKIM survives, and why relying on DKIM alignment tends to be the more robust path to a passing DMARC result. ### SPF limits and record hygiene SPF evaluation is capped at 10 DNS lookups. Every include:, a, mx, ptr and exists mechanism counts, and nested includes count too. Exceed 10 and receivers return a permerror, which is treated as a fail. Many domains hit this by chaining several SaaS senders. Keep one SPF record per domain - two v=spf1 TXT records is a permerror. Prefer include: for third-party senders over hard-coded ip4/ip6 blocks. Flatten only as a last resort, because flattening breaks when a provider changes its IPs. Choose your all mechanism deliberately. ~all (softfail) tells receivers to accept but mark suspicious mail from unlisted servers; -all (hardfail) tells them to reject it. A sample record: v=spf1 include:_spf.google.com include:sendgrid.net ~all ### The 2024 Gmail and Yahoo requirements Since February 2024, Gmail and Yahoo require bulk senders (those sending roughly 5,000 or more messages a day to their users) to authenticate with SPF and DKIM, keep valid forward and reverse DNS on the sending IP, honour one-click List-Unsubscribe, and stay under a spam-complaint threshold. Critically, they also require a DMARC record - even a monitoring-only one. In practice this makes DMARC effectively mandatory for any serious sending domain, not just bulk senders, because the same rules now gate deliverability across the largest mailbox providers. A safe starting DMARC record collects data without touching delivery: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Once your reports confirm all legitimate mail aligns, tighten p to quarantine and then reject. Glossary: - SPF (Sender Policy Framework): A DNS TXT record at the domain root that begins with v=spf1 and lists the servers authorised to send mail for the domain, ending with an all mechanism. Receivers check the sending IP against this list to see whether it is allowed to send as the domain. - DKIM (DomainKeys Identified Mail): An authentication method that publishes a public key in DNS at selector._domainkey.yourdomain.com while the sending server signs each message with the matching private key. The receiver verifies the signature to confirm the message was not altered in transit. - DMARC: A TXT record at _dmarc.yourdomain.com that sets the policy (p=none, p=quarantine or p=reject) for mail failing SPF or DKIM and can request aggregate reports via a rua address. It is the enforcement and reporting layer that ties SPF and DKIM together. - DMARC alignment: The requirement that the domain which passed SPF or DKIM matches the visible From header domain. SPF alignment compares the From domain to the Return-Path domain and DKIM alignment compares it to the signature's d= tag; a message passes DMARC when at least one of SPF or DKIM both passes and aligns. - DNS TXT record: A DNS record type that holds free-form text and carries email-authentication policies including SPF, the DKIM public key and DMARC. SPF and DMARC each require exactly one such record, and duplicates produce a permerror. - SPF 10-lookup limit: A cap of 10 DNS lookups when a receiver evaluates an SPF record, counting every include, a, mx, ptr and exists mechanism including nested includes. Exceeding it produces a permerror that is treated as an SPF failure. FAQ: Q: What is the difference between SPF, DKIM and DMARC? A: SPF authorises which servers may send for your domain, DKIM cryptographically signs each message so receivers can confirm it was not altered, and DMARC sets the policy for what happens when SPF or DKIM fails and gives you reporting. SPF and DKIM are the checks; DMARC is the enforcement and visibility layer on top. Q: What does ~all mean versus -all in an SPF record? A: Both are the final catch-all for servers not listed in your record. ~all is a softfail, meaning receivers should accept the mail but treat it as suspicious; -all is a hardfail, meaning they should reject it outright. Use ~all while you are still confirming every legitimate sender, then move to -all once you are confident the record is complete. Q: What is the SPF 10 DNS lookup limit? A: SPF allows at most 10 DNS lookups when a receiver evaluates your record. Each include, a, mx, ptr and exists mechanism counts, including nested includes inside other providers' records. Exceeding 10 produces a permerror, which is treated as an SPF failure, so keep your includes lean and remove senders you no longer use. Q: How do I find my DKIM selector? A: Send a message to an account you control, open the raw source, and look at the DKIM-Signature header. The s= tag is your selector and the d= tag is the signing domain. The public key then lives in DNS at selector._domainkey.d-domain. Your mail platform, such as Google Workspace or a marketing tool, also shows the selector when you set DKIM up. Q: What should my DMARC policy start at? A: Start at p=none with a rua address, for example v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. This monitors without affecting delivery and sends you aggregate reports. Once the reports confirm all your legitimate mail passes and aligns, move to p=quarantine and finally p=reject. Jumping straight to reject risks dropping real email. Q: Is DMARC now required for sending email? A: Effectively yes. Since February 2024, Gmail and Yahoo require bulk senders to publish a DMARC record along with valid SPF and DKIM. Because those two providers cover a large share of inboxes, most serious sending domains now need at least a p=none DMARC record to maintain deliverability, not only high-volume senders. Q: What is DMARC alignment and why does my mail fail it? A: Alignment requires the domain that passed SPF or DKIM to match the domain in the visible From header. SPF aligns against the Return-Path domain and DKIM aligns against the signature's d= domain. Mail often fails alignment when a third-party sender uses its own domain for the envelope or signature, so you must configure that provider to send or sign as your domain. Q: Why is my email still going to spam with all three records set? A: Authentication proves who you are, not that your content or IP is trusted. If SPF, DKIM and DMARC all pass but mail still lands in spam, check that the records actually align under DMARC, that your sending IP or domain is not on a blocklist, and that your content and sending reputation are healthy. Alignment and reputation are the usual culprits once the records themselves are correct. --- ## Blacklist check URL: https://servercake.in/tools/blacklist-checker Free blacklist checker. Test an IP or domain against Spamhaus ZEN, Barracuda, SORBS and other DNSBLs to find out why your email is bouncing or landing in spam. Key facts: - A DNSBL (DNS-based blocklist), also called an RBL, is a list of IP addresses or domains published over DNS that receiving mail servers query to decide whether to accept, reject or spam-folder a message. - A mail server checks an IP by reversing it, prepending it to the blocklist zone (for example 2.0.0.127.zen.spamhaus.org) and doing an A-record lookup, where a 127.0.0.x answer means listed and NXDOMAIN means clean. - Spamhaus ZEN is the most consequential blocklist because it combines the SBL, XBL, CSS and PBL sub-lists and is queried by a large share of receivers. - An IP blacklist judges the sending server's IP address, while a domain blacklist such as Spamhaus DBL or the SURBL/URIBL lists judges the domains and URLs inside the message body. - On shared hosting many sites share one public IP, so if a neighbour sends spam or gets compromised the whole IP can be listed and every tenant's mail is affected. ### What a DNSBL (RBL) actually is A DNSBL (DNS-based blocklist), also called an RBL (real-time blocklist), is a list of IP addresses or domains published over DNS that receiving mail servers query to decide whether to accept, reject or spam-folder an incoming message. When a server gets a connection from an IP, it reverses the IP, prepends it to the blocklist's zone (for example 2.0.0.127.zen.spamhaus.org) and does an A-record lookup. A returned 127.0.0.x answer means listed; NXDOMAIN means clean. This tool runs those same DNS queries for you against the major public lists at once, so instead of manually resolving each zone you get a single pass/fail per list. A listing does not physically block your server; it is a reputation signal that thousands of receivers consult on every SMTP connection. ### The lists that matter, and why Not all blocklists carry equal weight. Spamhaus ZEN is the one to watch: it is a combined zone bundling the SBL (spam sources), the CSS (snowshoe and low-reputation senders), the XBL (compromised or exploited machines, largely mirroring the CBL), and the PBL (IP ranges the operator says should never send mail directly, such as residential and dynamic pools). A hit on any of these shows up under ZEN, and a large share of the world's inbound mail is filtered against it. Barracuda Reputation Block List (BRBL) and SORBS are also widely consulted, and receivers like Microsoft and Google run their own internal reputation systems that no public tool can query. Treat a Spamhaus ZEN or Barracuda listing as high severity, and a hit on a small or aggressive niche list as lower priority - some receivers use it, many ignore it. ### IP blacklists vs domain blacklists These are two different reputation layers and both can sink a campaign. An IP blacklist (the DNSBLs above) judges the sending mail server's IP address. A domain blacklist judges the domains and URLs found inside the message body and headers - Spamhaus DBL and the SURBL/URIBL lists work this way, catching the domains spammers link to even when they rotate sending IPs. So your sending IP can be spotless while a link domain in your newsletter is flagged, or your IP can be listed while your domains are fine. Check both: if the IP is clean but mail still fails, inspect the domains and shortened URLs in your content, and confirm your From-domain authentication is aligned. ### Why an IP gets listed, including shared hosting Common triggers are outbound spam from a compromised account or web app, a misconfigured open relay or open proxy, a server infected and joined to a botnet, sending to spam-trap addresses, sudden unusual volume, or simply a weak sending history with no SPF/DKIM/DMARC to vouch for you. Poor sending reputation accumulates over time, so warming a new IP slowly matters. On shared hosting the IP is not yours alone. If a neighbour on the same address sends spam or gets compromised, the shared IP can be listed and every tenant's mail suffers, even senders who did nothing wrong. This is why serious senders use a dedicated IP or a reputable relay. If you inherited a fresh server, run this check first - the previous occupant's history may already be attached to the address. Glossary: - DNSBL / RBL: A DNS-based blocklist (also called a real-time blocklist) is a list of IP addresses or domains published over DNS that receiving mail servers query to decide whether to accept, reject or spam-folder a message. A returned 127.0.0.x answer means listed, while NXDOMAIN means clean. - Spamhaus ZEN: The most consequential blocklist, combining the SBL (spam sources), XBL (compromised machines), CSS (low-reputation senders) and PBL (IP ranges that should not send mail directly) into one queried zone. A large share of the world's inbound mail is filtered against it, so a hit is high severity. - Domain blacklist: A reputation list such as Spamhaus DBL or the SURBL/URIBL lists that judges the domains and URLs inside a message body rather than the sending IP. A sending IP can be clean while a link domain in the content is flagged, so both layers must be checked. - Sender reputation: The accumulated trust a sending IP or domain earns from its history, which receivers weigh on every SMTP connection. Outbound spam, hitting spam traps, sudden volume spikes and missing SPF/DKIM/DMARC all degrade it, which is why new IPs are warmed up slowly. - Delisting: The process of removing an IP or domain from a blocklist, done on the specific list's own removal page after the underlying abuse is fixed. Requesting removal without stopping the source usually results in being re-listed quickly. - Shared IP listing: A blocklisting that affects every tenant on a shared-hosting IP when one site on that address sends spam or is compromised. A dedicated IP or a reputable sending relay isolates a sender's reputation from neighbours on the same address. FAQ: Q: What is a DNSBL and how does it differ from an RBL? A: A DNSBL (DNS-based blocklist) is a list of IPs or domains published over DNS that mail servers query to filter incoming mail. RBL (real-time blocklist) is an older term for the same concept - the phrases are used interchangeably. A receiving server resolves your IP against the list's DNS zone; a 127.0.0.x answer means you are listed. Q: Which blacklists should I care about most? A: Spamhaus ZEN is the most consequential because it combines the SBL, XBL, CSS and PBL and is queried by a huge share of receivers. Barracuda (BRBL) and SORBS are also widely used. A hit on ZEN or Barracuda is high severity; a hit on a small niche list matters far less because most receivers do not consult it. Q: Why did my IP get blacklisted? A: Typical causes are outbound spam from a hacked account or web app, an open relay or open proxy, a botnet infection, hitting spam-trap addresses, an abrupt spike in volume, or a weak sending history with no email authentication. Listings reflect the address's behaviour, so identify and stop the source before asking for removal. Q: Can I be blacklisted because of another customer on shared hosting? A: Yes. On shared hosting many sites share one public IP, so if a neighbour sends spam or gets compromised the whole IP can be listed and every tenant's mail is affected, even innocent ones. A dedicated IP or a reputable sending relay isolates your reputation from neighbours. Q: How do I get removed from a blacklist? A: Fix the underlying problem first - secure compromised accounts, close any open relay, and verify SPF, DKIM and DMARC pass. Then submit a delisting request on the specific blocklist's own removal page (Spamhaus, Barracuda and SORBS each have their own). If you request removal without fixing the cause, you will usually be re-listed quickly. Q: What is the difference between an IP blacklist and a domain blacklist? A: An IP blacklist (a DNSBL) judges the sending server's IP address. A domain blacklist such as Spamhaus DBL or the SURBL/URIBL lists judges the domains and URLs inside the message. Your IP can be clean while a link domain in your content is flagged, or vice versa, so check both layers when mail fails. Q: Does being on a blacklist always mean my email is blocked? A: No. Each receiver chooses which lists to use and how to weight them - some reject outright, some only add spam score, and many ignore minor lists entirely. A Spamhaus ZEN listing usually causes real delivery failures, while a hit on an obscure list may have almost no effect. Still, treat any listing as worth resolving. Q: How long does a blacklist listing last? A: It varies by list. Some, like Spamhaus PBL and XBL entries, clear automatically once the bad behaviour stops or after you self-remove; others persist until you request delisting and pass review. Nothing clears if the abuse continues, so remediate the source, submit removal where required, then re-check before sending again. --- ## Password generator URL: https://servercake.in/tools/password-generator Free password and passphrase generator. Create strong random passwords of 8, 12, 16, 20 or 25 characters, or word-based passphrases, in bulk, all in your Key facts: - A password's strength is measured by its entropy in bits, which equals its length multiplied by log2 of the character-set size, so adding length raises strength faster than adding one more symbol. - For a 94-character printable ASCII set, a 12-character random password gives roughly 79 bits of entropy, a 16-character one about 105 bits and an 8-character one only about 52 bits. - A passphrase's strength comes from the word-list size and word count, and with a 7,776-word EFF/Diceware list each word adds about 12.9 bits, so four random words is about 51 bits. - A cryptographically secure password should be drawn from a secure random source such as the browser's crypto.getRandomValues Web Crypto API or Python's secrets module, not from Math.random. - NIST SP 800-63B advises favouring length, allowing all characters up to at least 64, screening against breached-password lists, and not forcing periodic rotation without a reason. ### Why length beats complexity A password's real strength is its entropy - the number of guesses an attacker needs on average, measured in bits. Entropy is length multiplied by log2 of the character-set size, so each extra character adds a fixed number of bits while the set stays the same. Adding length grows the search space far faster than adding one more symbol to a short password. For a set of 94 printable ASCII characters, each character is worth about 6.55 bits. A 12-character random password is roughly 79 bits; a 16-character one is about 105 bits; a 20-character one about 131 bits. This is why we default to 16 or more and offer 8, 12, 16, 20 and 25 - an 8-character password, even with symbols, is only about 52 bits and is brute-forceable offline. Complexity rules ('must contain an uppercase, a digit and a symbol') push people toward predictable patterns like 'Password1!' that machines guess quickly. A longer string from a mix of sets, or a multi-word passphrase, gives more real entropy than a short one bristling with special characters. ### Passphrases vs random strings A random string like 'k7$Qp2vX9mL!' is dense but hard to type and remember. A passphrase - several unrelated words chosen at random, such as 'harbor-violet-anchor-comet' - reaches the same entropy at a length you can actually memorise, which is why this tool offers a words mode. The strength of a passphrase comes from the size of the word list and the number of words, not from the words looking clever. With a 7,776-word list (the EFF/Diceware size) each word adds about 12.9 bits, so four random words is about 51 bits and six words is about 77 bits. Use passphrases for secrets you must type by hand - disk encryption, a password-manager master password, an SSH key passphrase - and random strings for everything a manager fills in for you. ### Generated in your browser, nothing sent anywhere Every password and passphrase here is created client-side using the browser's cryptographically secure generator (the Web Crypto crypto.getRandomValues API), not Math.random and not a server. The values never leave your machine, so they are not logged, transmitted or stored by us. This matters because a secret is only secret if nobody else ever saw it. Generating on a remote server, even over HTTPS, means the secret existed on someone else's machine. Generating locally means it exists only in your browser tab until you use it. You can confirm this yourself by loading the page and then turning off your network - generation still works. ### Use a password manager and never reuse The single most effective habit is a unique password for every account, stored in a password manager (Bitwarden, KeePassXC, 1Password or similar). Reuse is what turns one site's breach into a takeover of your email, bank and cloud console through credential-stuffing, where attackers replay leaked pairs across services. This lines up with NIST SP 800-63B, the widely cited guidance: favour length, allow all characters including spaces up to at least 64, screen new passwords against known-breached lists, and do NOT force periodic rotation without a reason - scheduled expiry pushes people toward weak, incremental passwords. Change a password when you have evidence it was exposed, not on a calendar. Let the manager generate and remember a long random secret per site, and protect the vault with a strong passphrase plus multi-factor authentication. Glossary: - Entropy: The measure of a password's strength in bits, equal to its length multiplied by log2 of the character-set size, representing how many guesses an attacker needs on average. Adding length raises entropy faster than adding one more symbol to a short password. - Passphrase: A secret made of several unrelated words chosen at random, such as harbor-violet-anchor-comet, that reaches high entropy while staying memorable. Its strength comes from the word-list size and word count; with a 7,776-word list each word adds about 12.9 bits. - Cryptographically secure random source: A generator suitable for secrets, such as the browser's crypto.getRandomValues Web Crypto API or Python's secrets module, whose output cannot be predicted. Ordinary functions like Math.random are not secure and must not be used to generate passwords. - Brute-force attack: An attack that tries every possible password until one matches, which offline against a leaked hash can reach billions of guesses per second on a GPU. An 8-character password of about 52 bits is brute-forceable this way, while length pushes the search space out of reach. - Password manager: Software such as Bitwarden, KeePassXC or 1Password that generates, stores and fills a unique long password for every account. Using one and never reusing a password stops a single site's breach turning into account takeover through credential-stuffing. - Credential stuffing: An attack that replays username-and-password pairs leaked from one breach against many other services, succeeding wherever a password was reused. A unique password per account, kept in a password manager, is the defence. FAQ: Q: Are the passwords generated on a server or sent anywhere? A: No. Every password is generated in your browser using the built-in cryptographically secure random generator (Web Crypto), and nothing is transmitted, logged or stored by us. You can even generate with your network disconnected. Q: How many characters should a password be? A: For a random password, 16 characters is a sensible default and gives roughly 105 bits of entropy with a full character set. Twelve is an acceptable minimum for online accounts, 20 or more suits high-value logins, and 8 is too short for anything you care about because it can be brute-forced offline. Q: What makes a password strong? A: Entropy, which comes mainly from length and from how many character sets you draw on. A long password or a multi-word passphrase beats a short one padded with symbols. Forced-complexity patterns like 'Password1!' are weak because attackers guess those shapes first. Q: Are random passwords or word-based passphrases better? A: Both can be equally strong; it depends on use. Random strings are ideal for anything a password manager fills in for you. Passphrases of four to six random words reach the same entropy while staying memorable, so use them for secrets you must type - a master password, disk encryption or an SSH key passphrase. Q: Should I ever reuse a generated password? A: No. Use a unique password for every account and keep them in a password manager. Reuse lets a breach on one site unlock the others through credential-stuffing, where attackers replay leaked username-and-password pairs across services. Q: How often should I change my passwords? A: Only when there is a reason - a breach, a suspected compromise or a shared secret leaving the team. NIST SP 800-63B advises against forced periodic rotation, because scheduled expiry pushes people toward weak, predictable changes. A long unique password in a manager plus MFA is stronger than one you keep rotating. Q: Can I generate many passwords at once? A: Yes. Bulk mode produces a whole list in one go, which is handy when you are seeding database users, VM credentials or test accounts and want a fresh, unique secret for each. They are generated locally like the single passwords. Q: Is this the same as generating a password in Python or a browser extension? A: The principle is the same - draw random bytes from a cryptographically secure source (Python's secrets module, or the browser's Web Crypto here) rather than an ordinary random function. This tool just puts a secure generator and passphrase mode in the browser with nothing installed and nothing sent to a server. --- ## JSON formatter & validator URL: https://servercake.in/tools/json-formatter Free JSON formatter and validator for developers. Beautify, validate or minify JSON in your browser with clear error messages. Nothing is uploaded to a server. Key facts: - JSON is defined by RFC 8259, requiring double-quoted strings and keys, and allowing only the lowercase literals true, false and null. - Formatting JSON adds indentation and line breaks for readability, while minifying strips insignificant whitespace, and both produce the same parsed value. - Standard JSON does not allow comments (// or /* */) or a trailing comma after the last array element or object member. - A trailing comma before a closing bracket or brace is one of the most common causes of invalid JSON. - Whitespace outside of string values has no meaning in JSON, so beautifying and minifying a document are lossless operations. ### Format, minify or validate JSON in one pass Paste raw JSON and the tool parses it, reports whether it is valid, and reprints it. Formatting (also called beautifying or pretty-printing) adds line breaks and consistent indentation so nested objects and arrays are easy to scan. Minifying does the opposite: it strips every space, tab and newline that sits between tokens, producing the smallest byte-equivalent output for transport or storage. Both operations are lossless. Whitespace outside of string values carries no meaning in JSON, so a beautified document and its minified form parse to exactly the same value. Use formatting when you are reading or diffing a payload, and minify when you are shipping it over the wire or embedding it in a config. ### JSON syntax rules the validator enforces JSON is defined by RFC 8259 and json.org, and the grammar is strict. Strings and object keys must use double quotes, never single quotes, and keys are always quoted. Numbers use a JSON literal form (no leading zeros, no hex, no NaN or Infinity). The only allowed literals are true, false and null, all lowercase. Trailing commas are not allowed after the last element of an array or the last member of an object. Comments are not part of JSON at all, so // and /* */ will fail even though many editors tolerate them in config files. If you need comments, you are working with JSON5 or JSONC, not standard JSON, and those will not pass a strict parser. ### Reading validation errors When parsing fails the tool surfaces the underlying error and points at the position where it broke. The most common message developers hit is "Unexpected token", which means the parser found a character it could not use in that spot - often a stray comma, a single quote, an unquoted key, or a value that was never closed. A trailing comma before a closing bracket or brace is the single most frequent cause of invalid JSON, especially when a payload is hand-edited or assembled by string concatenation. Other repeat offenders are missing commas between elements, missing closing brackets, and control characters that were not escaped inside a string. The reported line and column narrow the search to a few characters. ### Runs in your browser - safe for real payloads All parsing, formatting, minifying and validation happen locally in your browser using the native JSON engine. Nothing you paste is uploaded to a server or logged, so you can safely work with API responses, environment configs, webhook bodies or other sensitive data without it leaving your machine. That matters for anyone handling production data. ServerCake runs developer infrastructure in India, and we keep these small tools client-side on purpose so an internal token or customer record never travels to a third party just to be pretty-printed. Glossary: - JSON (JavaScript Object Notation): JSON is a text data format, defined by RFC 8259, that represents structured data as objects, arrays, strings, numbers and the literals true, false and null. Strings and object keys must be wrapped in double quotes. - Beautify (pretty-print): Beautifying reprints JSON with line breaks and consistent indentation so nested objects and arrays are readable. It changes only whitespace, so the parsed value is identical to the compact form. - Minify: Minifying strips every space, tab and newline between tokens to produce the smallest byte-equivalent JSON for transport or storage. Because whitespace outside strings has no meaning, the operation is lossless. - Validation: Validation parses text against the JSON grammar and reports whether it is well-formed. Common failures include trailing commas, single quotes instead of double quotes, unquoted keys and unclosed brackets. - Trailing comma: A trailing comma is a comma left after the last element of an array or last member of an object. Standard JSON forbids it, and it is one of the most frequent causes of an invalid document. - JSON5 / JSONC: JSON5 and JSONC are relaxed supersets of JSON that permit comments and trailing commas. They are separate formats and will fail a strict RFC 8259 parser. FAQ: Q: Is my JSON sent to a server? A: No. Formatting, validation and minifying all happen in your browser using the native JSON engine, so you can safely paste config, tokens or API data without it leaving your machine. Q: What is the difference between formatting and minifying? A: Formatting (beautifying) adds indentation and line breaks so the JSON is easy to read. Minifying strips all whitespace between tokens to make the payload as small as possible for transport. Both produce the same parsed value - only the whitespace differs. Q: Why does it say my JSON is invalid? A: The most common causes are a trailing comma before a closing bracket or brace, single quotes instead of double quotes, unquoted keys, comments (// or /* */, which JSON does not allow), or a missing bracket. The validator points to where parsing failed so you can fix that spot. Q: What does the error 'Unexpected token' mean? A: It means the parser reached a character it cannot use in that position - typically a stray or trailing comma, a single quote, an unquoted key, or a value that was never closed. The reported line and column tell you where to look. Q: Is this a JSON validator as well as a beautifier? A: Yes. Every format or minify pass first parses the input against the JSON grammar from RFC 8259, so an invalid document is reported before it is reprinted. It works as a validator, formatter, beautifier and minifier in one tool. Q: Can I change the indentation of the output? A: Yes. You can pretty-print with 2-space or 4-space indentation. Two spaces is the most common convention for JSON files and API payloads, while four spaces is sometimes used to match a wider codebase style. Q: Are comments or trailing commas allowed in JSON? A: No. Standard JSON, as defined by RFC 8259, does not allow comments (// or /* */) or trailing commas after the last item. If you need those, you are using JSON5 or JSONC, which are separate formats and will not pass a strict JSON parser. Q: Can this convert JSON to CSV or view it as a tree? A: This tool focuses on formatting, validating and minifying JSON text. It does not convert JSON to CSV or render an interactive tree viewer; for those, format the JSON here first so it parses cleanly, then feed the valid output into a dedicated converter or viewer. --- ## JWT decoder URL: https://servercake.in/tools/jwt-decoder Free JWT decoder for developers. Paste a token to read its header, payload and standard claims in your browser. Nothing is sent to a server, so it is safe. Key facts: - A JWT is a compact string of three Base64url parts joined by dots: header, payload and signature. - A JWT header and payload are Base64url encoded, not encrypted, so anyone holding the token can read them without a key. - Decoding a JWT is not the same as verifying it, because only checking the signature with the signing key proves the token is authentic. - RFC 7519 registered claims include iss, sub, aud, exp, iat, nbf and jti, where exp, iat and nbf are Unix timestamps in seconds. - HS256 is symmetric HMAC-SHA256 using one shared secret, while RS256 is asymmetric RSA-SHA256 where a private key signs and the public key verifies. ### What a JWT actually is A JSON Web Token (JWT) is a compact, URL-safe string made of three parts joined by dots: header.payload.signature. The header and payload are JSON objects that are Base64url encoded (not encrypted), and the signature is a keyed hash or digital signature over the first two parts. Because the header and payload are only encoded, anyone who holds the token can decode and read them without any key. Decoding just reverses that Base64url step and pretty-prints the JSON. This tool does exactly that, in your browser - nothing is uploaded to a server. ### Standard claims you will see The payload carries claims - name/value pairs describing the token. The RFC 7519 registered claims are: iss (issuer), sub (subject, usually the user id), aud (audience the token is intended for), exp (expiry as a Unix timestamp), iat (issued-at), nbf (not-before), and jti (a unique token id). All time claims are seconds since the Unix epoch, so exp of 1735689600 is a date, not a duration. Everything else is a custom claim your app defined - roles, tenant id, email, scopes. Remember the payload is world-readable, so never put passwords, API keys, or other secrets in it. ### Algorithms: HS256 vs RS256 The header's alg field names the signing algorithm. HS256 is HMAC with SHA-256 - a symmetric scheme where the same secret both signs and verifies, so every service that verifies must hold the shared secret. RS256 is RSA with SHA-256 - asymmetric, so a private key signs and only the matching public key is needed to verify, which is safer for tokens verified by many parties (for example via a JWKS endpoint). Watch the alg: none pitfall. A token can claim alg: none to declare it is unsigned. A correctly configured verifier must reject none (and reject a token whose alg does not match what you expect), otherwise an attacker can strip the signature and forge claims. Decoding a token here shows you its alg but does not act on it. ### Decoding is not verifying This is the point that trips people up: reading a token's contents proves nothing about its authenticity. A decoded token is not a validated token. The signature is what proves it was issued by a trusted party and not tampered with, and checking the signature requires the signing key (the HMAC secret or the RSA/EC public key) plus checks on exp, nbf, iss and aud. So never trust an unverified token. Verification belongs on your server or gateway using a maintained library - jsonwebtoken or jose in Node, PyJWT in Python, golang-jwt in Go - never by eyeballing the payload. Use this decoder to inspect and debug what a token contains, not to decide whether to trust it. Glossary: - JWT (JSON Web Token): A JWT is a compact, URL-safe string made of three Base64url parts joined by dots: header, payload and signature. It carries claims about a subject and is defined by RFC 7519. - Header: The header is the first JWT segment, a Base64url-encoded JSON object naming the token type and the signing algorithm in its alg field, such as HS256 or RS256. - Payload: The payload is the middle JWT segment holding the claims as a Base64url-encoded JSON object. It is encoded, not encrypted, so anyone holding the token can read it - never place secrets there. - Signature: The signature is the third JWT segment, a keyed hash or digital signature over the header and payload. Checking it with the signing key is what proves the token is authentic and untampered. - Registered claims (iss, sub, exp): Registered claims are the standard fields RFC 7519 defines, including iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued-at) and nbf (not-before). The time claims are Unix timestamps in seconds. - HS256 vs RS256: HS256 is symmetric HMAC-SHA256, where one shared secret both signs and verifies. RS256 is asymmetric RSA-SHA256, where a private key signs and the matching public key verifies, suiting tokens checked by many parties. FAQ: Q: Is my token sent to a server? A: No. The token is decoded entirely in your browser using JavaScript, so even a real, live JWT never leaves your machine. That makes it safe to paste tokens here. Q: Should I paste a production token into an online JWT decoder? A: Only into a decoder that runs fully in your browser, like this one. A JWT is a live credential, so pasting it into a tool that sends it to a server means handing your credential to that server. As a habit, never paste secret-bearing production tokens into online tools whose behaviour you cannot see; prefer an in-browser or CLI decoder. Q: Does this verify the signature? A: No. Decoding shows what the token contains, but it does not check that the signature is valid. Verification needs the signing key (the HMAC secret or the public key) and checks on exp, iss and aud, and it should happen on your server, not in a browser tool. Q: Why can I read the payload without a key? A: A JWT's header and payload are only Base64url encoded, not encrypted, so anyone holding the token can decode and read them. The signature is what proves the token was not tampered with. Because the payload is readable by anyone, never put passwords or secrets in it. Q: What is the difference between HS256 and RS256? A: HS256 is symmetric HMAC-SHA256: one shared secret both signs and verifies, so every verifier must hold that secret. RS256 is asymmetric RSA-SHA256: a private key signs and only the public key is needed to verify, which suits tokens verified by many services, often via a JWKS endpoint. Q: What does 'alg: none' mean and why is it dangerous? A: 'alg: none' declares that a token is unsigned. If a verifier accepts it, an attacker can remove the signature and forge any claims they like. A correct verifier must reject 'none' and reject any token whose algorithm does not match what the application expects. Q: How do I read the exp and iat claims? A: exp (expiry) and iat (issued-at) are Unix timestamps - seconds since 1 Jan 1970 UTC. Convert the number to a date to check whether the token is expired. nbf (not-before) works the same way and marks the earliest time the token is valid. Q: Can I decode a JWT from the command line? A: Yes. A JWT is three Base64url parts split by dots, so you can decode the payload with a one-liner, for example: echo TOKEN | cut -d. -f2 | base64 -d. On many systems you may need to pad the string or use base64url decoding; a small script or a library like jose or PyJWT is more reliable for automation. --- ## Base64 encode / decode URL: https://servercake.in/tools/base64 Free Base64 encode and decode tool. Convert text or files to Base64 and back, with base64url support, right in your browser and nothing sent to a server. Key facts: - Base64 is a binary-to-text encoding that represents bytes using 64 printable ASCII characters: A-Z, a-z, 0-9, plus (+) and slash (/). - Base64 encodes 3 bytes into 4 characters, making the output about 33 percent larger than the input. - Base64 is encoding, not encryption, because anyone can decode a Base64 string back to the original bytes with no key. - The base64url variant defined in RFC 4648 replaces + and / with - and _ so the output is safe in URLs, filenames and JWTs. - The = character is padding added so the output length is a multiple of four, and base64url often omits it. ### What Base64 is Base64 is a binary-to-text encoding. It takes raw bytes and represents them using only 64 safe printable ASCII characters - A-Z, a-z, 0-9 and two symbols (+ and /) - so binary data can pass through systems that expect plain text. It works in groups of 3 bytes (24 bits), which split into four 6-bit values, each mapping to one character in the 64-character alphabet. Because 3 bytes become 4 characters, the output is about 33% larger than the input. A tiny example: the text 'Man' encodes to 'TWFu'. Decoding 'TWFu' gives back 'Man' exactly, byte for byte. ### Encoding is not encryption Base64 is encoding, not encryption. It hides nothing - anyone can decode a Base64 string back to the original bytes with no key and no secret. Do not use it to protect passwords, tokens or any sensitive data. A common example is the HTTP Basic auth header: 'Authorization: Basic dXNlcjpwYXNz' is just 'user:pass' Base64-encoded, which is why Basic auth is only safe over HTTPS. Likewise a JWT's header and payload are Base64url, not encrypted, so never put secrets in them. ### Where developers use it Data URIs: embed a small image or font directly in HTML or CSS as data:image/png;base64,... so it loads without a separate request. Good for tiny assets; large ones bloat the file by ~33%. Email (MIME): attachments and non-ASCII bodies are Base64-encoded so 8-bit binary survives mail servers that were built for 7-bit text. APIs and JSON: JSON has no binary type, so file contents, images or raw bytes are carried as a Base64 string field. Config and secrets files: certificates, keys and blobs are often stored Base64-encoded so they fit on a single text line (encoded, still not encrypted). ### Base64 vs base64url and padding Standard Base64 uses + and / as its last two characters, but those are unsafe in URLs and filenames. The base64url variant (RFC 4648) swaps them for - and _ so the output can go straight into a query string, a path segment or a JWT. The = character is padding. Since input is processed in 3-byte blocks, a final block of 1 or 2 bytes is padded with = so the output length is always a multiple of 4. base64url often drops the padding entirely. So the same bytes can appear as 'a+b/c==' in standard Base64 or 'a-b_c' in unpadded base64url. Decode with the matching variant or you will get errors or wrong bytes. Glossary: - Base64: Base64 is a binary-to-text encoding that represents bytes using 64 printable ASCII characters (A-Z, a-z, 0-9, plus and slash), so binary data can pass through text-only systems. Every 3 bytes become 4 characters. - Encoding vs encryption: Base64 is encoding, not encryption: there is no key and anyone can decode a string back to the original bytes. It must never be used to protect passwords, tokens or other secrets. - base64url: base64url is a URL-safe variant defined in RFC 4648 that replaces the plus and slash characters with hyphen and underscore, so the output is safe in URLs, filenames and JWTs, and often omits padding. - Padding: Padding is the equals character added so the output length is a multiple of four. A final block of one byte gets two equals signs and a block of two bytes gets one; base64url frequently drops it. - Size overhead: Base64 output is about 33 percent larger than the input because three input bytes are represented by four output characters. This is why data URIs suit small assets rather than large files. - Data URI: A data URI embeds bytes inline as data:mediatype;base64,DATA so a small image or font can load directly from HTML or CSS without a separate request. The part after the comma is the Base64 payload. FAQ: Q: Is my text sent to a server? A: No. Encoding and decoding happen entirely in your browser, so any text, token or file you paste stays on your machine and is never uploaded. Q: How do I decode a Base64 string? A: Paste the string, choose 'Decode', and the original text or bytes appear. For example 'TWFu' decodes to 'Man'. If it fails, check for a wrong variant (standard vs base64url) or stray whitespace and characters that are not part of Base64. Q: How do I encode text to Base64? A: Paste the text, choose 'Encode', and read the result. The output uses the 64-character alphabet (A-Z, a-z, 0-9, + and /) and is about 33% longer than the input, since every 3 bytes become 4 characters. Q: Can I decode Base64 to an image or PDF? A: Yes. Decode the Base64 string, then download the result as a file. If the data starts as a data URI like 'data:image/png;base64,...', strip everything up to and including the comma first, then decode the part that follows. Q: Is Base64 a form of encryption? A: No. Base64 is encoding, not encryption. There is no key and anyone can decode it back to the original bytes, so never use it to protect passwords, API keys or secrets. Q: What is the difference between Base64 and base64url? A: They share the same alphabet except for the last two characters. Standard Base64 uses + and /, while the URL-safe base64url variant uses - and _ so the output is safe in URLs, filenames and JWTs. base64url also often omits the = padding. Q: Why does Base64 end with one or two = signs? A: The = is padding. Input is encoded in blocks of 3 bytes; when the last block has only 1 or 2 bytes, = characters are added so the output length is always a multiple of four. A final block of 1 byte gets '==' and 2 bytes gets '='. Q: Does Base64 make my data larger? A: Yes, by roughly 33%. Three bytes of input become four Base64 characters, so a 300 KB file becomes about 400 KB encoded. That is why data URIs suit small assets, not large ones. --- ## UUID generator URL: https://servercake.in/tools/uuid-generator Free online UUID generator. Create RFC 9562 UUID v4 (random), v1 and v7 identifiers, single or in bulk, entirely in your browser. Copy-ready GUIDs, no server Key facts: - A UUID (also called a GUID) is a 128-bit identifier written as 32 hexadecimal digits in the 8-4-4-4-12 grouping, for a total of 36 characters. - UUID format and version rules are defined by RFC 9562, which replaced the older RFC 4122 in 2024. - A UUID version 4 is almost entirely random, with 122 random bits and only the version and variant bits fixed. - A UUID version 7 places a Unix millisecond timestamp in its high bits followed by random bits, making values time-ordered and index-friendly. - The collision probability of random v4 UUIDs is negligible for real workloads, so they can be treated as unique without checks. ### What a UUID (GUID) actually is A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) on Microsoft platforms, is a 128-bit value used to label something uniquely without a central authority handing out numbers. The two names refer to the same thing. It is written as 36 characters: 32 hexadecimal digits in five groups separated by hyphens, in the 8-4-4-4-12 pattern, for example 550e8400-e29b-41d4-a716-446655440000. The hyphens are part of the canonical text form; the raw value is still just 128 bits. The format and version rules are defined by RFC 9562, which in 2024 replaced the older RFC 4122. Anything you generate here follows that specification, so it is valid input for languages and databases that parse UUIDs. ### UUID versions: v4, v1 and v7 Version 4 is the one most developers reach for. Almost all of its bits are random, with a fixed version and variant nibble, so you can mint them anywhere with no coordination. This tool defaults to v4. Version 1 encodes a 60-bit timestamp plus a node identifier historically derived from the MAC address. It is sortable by creation time but can leak the machine and clock, which is why many teams avoid it. Version 7 is the newer, recommended choice for database keys. It puts a Unix millisecond timestamp in the high bits followed by random bits, so values are time-ordered and index-friendly like v1, but without exposing hardware. If you are picking a primary-key UUID today, v7 is usually the better default over v1. ### Collision probability and why v4 is safe A v4 UUID has 122 random bits (six are fixed for version and variant). That is roughly 5.3 x 10^36 possible values, so the chance of two independently generated v4 UUIDs colliding is negligible for any real workload. As a rule of thumb, you would need to generate on the order of a billion UUIDs per second for about 85 years to reach a 50 percent chance of a single collision. In practice you can treat v4 as unique and skip uniqueness checks in application code. Randomness quality matters: this generator uses the browser's crypto secure random source, not the weaker Math.random, so the entropy behind each value is cryptographically strong. ### UUID vs auto-increment IDs in databases Auto-increment integers are compact, fast to index, and human-readable, but they are guessable, reveal row counts, and require the database to assign them, which complicates sharding, offline creation and merging data from multiple sources. UUIDs let any client or service generate a key up front without a round-trip, and they stay unique across shards and systems. The trade-off is size (16 bytes vs 4 or 8) and, for random v4, index fragmentation because inserts land in random positions. Time-ordered v7 is the usual answer to that fragmentation: you keep global uniqueness and client-side generation while inserts stay roughly sequential, which is kinder to B-tree indexes on Postgres or MySQL. When you provision a managed Postgres instance on ServerCake, storing keys as a native uuid type keeps them 16 bytes rather than 36-character text. Glossary: - UUID / GUID: A UUID (Universally Unique Identifier), also called a GUID on Microsoft platforms, is a 128-bit value used to label something uniquely without a central authority. Both names refer to the same thing. - Canonical 8-4-4-4-12 format: A UUID is written as 36 characters: 32 hexadecimal digits in five hyphen-separated groups of 8, 4, 4, 4 and 12 digits. The hyphens are part of the text form while the raw value stays 128 bits. - UUID version 4: A UUID version 4 is almost entirely random, with 122 random bits and only the version and variant bits fixed. It can be generated anywhere without coordination and is the most common version. - UUID version 7: A UUID version 7 places a Unix millisecond timestamp in its high bits followed by random bits, making values time-ordered and index-friendly. It is the recommended choice for database primary keys. - RFC 9562: RFC 9562 is the 2024 specification that defines UUID format and version rules, replacing the older RFC 4122 and adding versions 6, 7 and 8. - Collision probability: Collision probability is the chance two independently generated UUIDs are identical. For random v4 UUIDs, with about 5.3 x 10^36 possible values, it is negligible for real workloads, so they can be treated as unique. FAQ: Q: What is the difference between a UUID and a GUID? A: There is no technical difference. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit value that the RFC 9562 standard calls a UUID. Both use the 36-character 8-4-4-4-12 hex format, so a GUID from C# or PowerShell and a UUID from Python or Java are fully interchangeable. Q: What is a UUID v4 and when should I use it? A: A UUID v4 is an identifier whose bits are almost entirely random, with only the version and variant fixed. Use it whenever you need a unique id and do not care about ordering, such as request IDs, API keys or object identifiers. It is the most common version and the default in most libraries. Q: Should I use UUID v4 or v7 for a database primary key? A: Prefer v7 for primary keys. v4 is fully random, so rows insert in random index positions and can fragment a B-tree index. v7 starts with a millisecond timestamp, so values are time-ordered and insert sequentially while staying globally unique. Both are valid RFC 9562 UUIDs; v7 is simply friendlier to indexes. Q: How likely is a UUID v4 collision? A: Effectively zero for real workloads. A v4 UUID has 122 random bits, about 5.3 x 10^36 possibilities. You would need to generate roughly a billion per second for about 85 years to reach a 50 percent chance of one collision, so you can safely treat v4 values as unique without checking. Q: Can I generate UUIDs in bulk? A: Yes. Switch to bulk mode, enter how many you need, and the tool returns a list you can copy in one go. This is handy for seeding database rows, generating test fixtures or pre-allocating IDs for a batch import. Q: Are these UUIDs generated online on your server? A: No. Every UUID is created locally in your browser using the built-in crypto secure random generator. Nothing you generate is sent to, logged by or stored on a server, so the values are private to you. Q: How do I generate a UUID in Python, JavaScript, Java or C#? A: Python: import uuid then uuid.uuid4(). JavaScript in the browser or Node 19+: crypto.randomUUID(). Java: java.util.UUID.randomUUID(). C#: Guid.NewGuid(). All produce a v4 value. This tool is useful when you want valid UUIDs without running code, or to double-check a format. Q: Is a UUID always 36 characters long? A: In its standard text form, yes: 32 hexadecimal digits plus 4 hyphens equals 36 characters, in the 8-4-4-4-12 grouping. Some systems store it as a 32-character hyphen-free string, wrap it in braces like a Windows GUID, or keep it as a compact 16-byte binary value, but they all represent the same 128 bits. --- ## Hash generator URL: https://servercake.in/tools/hash-generator Free in-browser hash generator. Compute MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests of any text. Learn which to use and why raw hashes fail for passwords. Key facts: - A cryptographic hash function turns any input into a fixed-length digest, is deterministic and one-way, and cannot be reversed to recover the original input. - SHA-256 always produces a 256-bit (64 hex character) digest, while SHA-512 produces a 512-bit (128 hex character) digest; both belong to the secure SHA-2 family. - MD5 (128-bit) and SHA-1 (160-bit) are cryptographically broken with practical collisions, so they must not be used for signatures, certificates or any security decision. - Hashing differs from encryption because it is one-way and keyless with no decrypt operation, whereas encryption is reversible with the correct key. - Raw general-purpose hashes are unsuitable for storing passwords because GPUs guess billions per second; use a slow, salted, memory-hard function such as Argon2id, scrypt or bcrypt instead. ### What a cryptographic hash actually is A cryptographic hash function takes any input - a word, a paragraph, or a multi-gigabyte file - and produces a fixed-length string of bytes called a digest. SHA-256 always returns 256 bits (64 hex characters), whether you feed it one letter or an entire ISO image. Three properties define a good hash function. It is deterministic: the same input always yields the same digest, which is what makes hashes useful for verification. It is one-way (pre-image resistant): given a digest, there is no practical way to recover the original input. And it should be collision resistant: it must be infeasible to find two different inputs that produce the same digest. It also exhibits the avalanche effect. Change a single bit of the input - flip one character, add a trailing space - and roughly half the output bits flip, producing a completely different-looking digest. This is why a hash is a reliable fingerprint: any tampering, however small, is immediately visible as a different value. This tool computes the digest for text you type, entirely in your browser. ### Hashing is not encryption These two are constantly confused, and the difference matters. Encryption is reversible by design: you encrypt plaintext with a key, and anyone with the correct key can decrypt it back to the original. It protects confidentiality of data you need to read again later. Hashing is one-way and keyless: there is no decrypt operation, and no key that turns a digest back into its input. You cannot decrypt a hash - if a tool claims to decrypt MD5 or SHA-256, it is really doing a reverse lookup against a precomputed table of common inputs, not reversing the maths. Use encryption (AES-256-GCM, for example) when you must recover the plaintext, such as storing an API secret you will call later. Use hashing when you only ever need to check whether something matches or has changed - verifying a download, deduplicating data, or checking a password against a stored value without keeping the password itself. ### MD5, SHA-1, SHA-256 and SHA-512 - which to use MD5 produces a 128-bit digest and is cryptographically broken. Practical collision attacks have existed since 2004, so MD5 must never be used for signatures, certificates, or any security decision. It survives only as a fast, non-security checksum for detecting accidental corruption or deduplicating files, where an attacker is not in the picture. SHA-1 (160-bit) is also deprecated. The 2017 SHATTERED attack produced a real-world collision, and browsers and certificate authorities dropped it years ago. Do not use it for anything new. The current safe default is the SHA-2 family: SHA-256 for general integrity and signing, and SHA-384 or SHA-512 when you want a larger margin (SHA-512 is often faster on 64-bit CPUs). SHA-3 exists as a structurally different backup, but SHA-256 remains the workhorse for most integrity and signing needs today. ### Never store passwords with a raw hash This is the single most important rule. A plain SHA-256 (or MD5, or SHA-512) of a password is not safe storage, even though it is one-way. General-purpose hashes are designed to be fast, so a modern GPU can compute billions of SHA-256 guesses per second, tearing through leaked hashes with dictionaries and rainbow tables. Hashing without a per-user salt also means identical passwords produce identical digests, exposing reuse. For passwords, use a purpose-built password hashing function: Argon2id (the current recommendation), scrypt, or bcrypt. These are deliberately slow and memory-hard, they generate and store a unique random salt per password, and their cost factor is tunable so you can keep them expensive as hardware improves. This browser tool intentionally implements only general-purpose hashes for checksums and integrity - do not paste user passwords into any hasher and store the output. Reach for Argon2id, scrypt, or bcrypt in your application code instead. Glossary: - Digest: The fixed-length output a hash function produces from any input, serving as a fingerprint of that data. SHA-256 always returns 256 bits (64 hex characters) and SHA-512 returns 512 bits (128 hex characters), whatever the input size. - One-way (pre-image resistance): The property that a digest cannot be reversed to recover the original input, since hashing is keyless with no decrypt operation. Tools claiming to decrypt a hash are doing a reverse lookup against precomputed tables of common inputs, not reversing the maths. - Salt: A unique random value added to each input before hashing so that two identical passwords produce different stored digests. It defeats precomputed rainbow tables because an attacker cannot prepare tables in advance for unseen salts; proper password hashers generate and store it automatically. - Collision resistance: The property that it is infeasible to find two different inputs producing the same digest. Collisions have been produced in practice for MD5 and SHA-1, which is why those functions are no longer trusted for signatures, certificates or any security decision. - bcrypt: A purpose-built password-hashing function that is deliberately slow, generates a per-password salt, and has a tunable cost factor to stay expensive as hardware improves. It and its alternatives Argon2id and scrypt should be used for passwords instead of a fast general-purpose hash like SHA-256. - Avalanche effect: The behaviour where changing a single bit of the input flips roughly half the output bits, producing a completely different digest. This is what makes a hash a reliable integrity fingerprint, since any tampering shows up as a different value. FAQ: Q: Can I decrypt or reverse an MD5 or SHA-256 hash? A: No. Hashing is one-way, so there is no decrypt operation and no key that turns a digest back into its input. Sites that claim to decrypt a hash are doing a reverse lookup against a stored table of common inputs and their known hashes - they only work for weak or previously seen values, never by reversing the maths. Q: Is MD5 safe to use? A: Only for non-security checksums, such as detecting accidental file corruption or deduplicating data. MD5 is cryptographically broken - practical collisions have existed since 2004 - so never use it for passwords, digital signatures, certificates, or any decision an attacker could influence. Use SHA-256 there instead. Q: How do I generate a SHA-256 checksum of a file? A: This tool hashes text, so for a file use your operating system. On Linux run sha256sum filename, on macOS run shasum -a 256 filename, and on Windows run Get-FileHash filename in PowerShell (SHA-256 is its default). Then compare the output against the vendor's published SHA-256 value. Q: Should I store user passwords as SHA-256 hashes? A: No. Fast general-purpose hashes like SHA-256 can be brute-forced at billions of guesses per second on a GPU, and without a per-user salt identical passwords give identical hashes. Use a slow, salted, memory-hard password hash instead: Argon2id is the current recommendation, with scrypt or bcrypt as accepted alternatives. Q: What is a salt and why does it matter? A: A salt is a unique random value added to each input before hashing. It ensures two users with the same password get different stored hashes, and it defeats precomputed rainbow tables because an attacker cannot prepare tables in advance for salts they have not seen. Proper password hashers like Argon2id and bcrypt generate and store the salt for you automatically. Q: What is the difference between SHA-256 and SHA-512? A: Both are members of the SHA-2 family and both are secure. SHA-256 produces a 256-bit (64 hex character) digest and is the common default; SHA-512 produces a 512-bit (128 hex character) digest for a larger security margin, and it is often faster on 64-bit processors. For most integrity and signing work SHA-256 is plenty. Q: Do two different inputs ever produce the same hash? A: A collision - two inputs sharing one digest - is mathematically possible for any hash because inputs are unlimited and outputs are fixed length. For a strong function like SHA-256 finding one is computationally infeasible. For MD5 and SHA-1 collisions have been produced in practice, which is exactly why those two are no longer trusted for security. Q: Is my input sent to a ServerCake server? A: No. All hashing runs in your browser using the Web Crypto API, so the text you enter never leaves your device and nothing is uploaded or logged. You can confirm this by disconnecting from the network - the tool keeps working offline. --- ## Crontab builder & explainer URL: https://servercake.in/tools/crontab-generator Free crontab generator and cron expression explainer. Build a schedule from simple fields, read what it runs in plain English, with worked examples. No sign-up. Key facts: - A standard cron expression has five space-separated fields in order: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12) and day-of-week (0-6, where 0 is Sunday). - The expression 0 2 * * * runs a job at 02:00 every day, and */15 * * * * runs every 15 minutes. - Cron operators are the star (every value), comma (a list), hyphen (a range) and slash (a step), so */10 means every 10th value. - When both day-of-month and day-of-week are restricted, cron runs the job when either matches, not both. - Cron uses the server's local timezone unless it is configured otherwise, so a schedule fires in whatever zone the machine is set to. ### The five cron fields A standard cron expression is five space-separated fields, in this fixed order: minute (0-59), hour (0-23, on a 24-hour clock), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Some systems also accept 7 for Sunday and three-letter names like jan or mon. Read left to right as 'at minute M, at hour H, on day-of-month D, in month N, on weekday W'. So 30 6 1 * * means 06:30 on the 1st of every month. The sixth-field 'seconds' variant you may see in Quartz or systemd is not standard Unix cron - classic crontab has exactly five fields. Each field can hold a single number, or one of the special characters below to cover multiple values. ### Special characters and macros Four operators do most of the work. A star (*) means 'every value' for that field. A comma builds a list, so 0,15,30,45 means those four minutes. A hyphen builds a range, so mon-fri in the weekday field means Monday through Friday. A slash sets a step, so */15 in the minute field means every 15th minute (0,15,30,45), and 0-30/10 means 0,10,20,30. Most cron implementations also accept shorthand macros in place of the five fields: @yearly (or @annually) = 0 0 1 1 *, @monthly = 0 0 1 * *, @weekly = 0 0 * * 0, @daily (or @midnight) = 0 0 * * *, and @hourly = 0 * * * *. There is also @reboot, which runs once when cron starts after a boot rather than on a clock schedule. This builder lets you pick these visually and shows the resulting expression, so you do not have to memorise the operators. It reads back a plain-English description too, the same idea as crontab.guru. ### Worked examples * * * * * runs every minute. */15 * * * * runs every 15 minutes. 0 * * * * runs at the top of every hour. 0 2 * * * runs at 02:00 every day - a common choice for nightly backups. 30 9 * * 1-5 runs at 09:30 on weekdays only. 0 0 * * 1 runs at midnight every Monday. 0 */6 * * * runs every 6 hours (00:00, 06:00, 12:00, 18:00). 0 0 1 * * runs at midnight on the 1st of each month. 0 22 * * 6 runs at 22:00 every Saturday. ### Two things that trip people up The day-of-month / day-of-week OR gotcha: when BOTH the day-of-month and day-of-week fields are restricted (neither is *), cron runs the job when EITHER matches, not both. So 0 0 13 * 5 runs at midnight on the 13th AND on every Friday - not only on Friday the 13th. To require both conditions you generally test one of them inside the command itself. Timezone: cron uses the server's local time, not UTC and not your laptop's time. A job set for 0 2 * * * fires at 02:00 in whatever timezone the machine is configured to. On an India VM, confirm the clock is IST (run timedatectl) before you rely on the schedule, or your 2am job may actually run at 07:30 IST if the box is on UTC. Glossary: - Cron expression: A standard cron expression is five space-separated fields, in order minute (0-59), hour (0-23), day-of-month (1-31), month (1-12) and day-of-week (0-6, where 0 is Sunday), that define when a job runs. - Field operators: Cron field operators are the star for every value, the comma for a list, the hyphen for a range and the slash for a step. For example 0,15,30,45 is a list and mon-fri is a range. - Step value: A step value uses a slash to run at a fixed interval within a field, so */15 in the minute field means every 15th minute (0, 15, 30, 45) and 0-30/10 means 0, 10, 20, 30. - Macro (@daily): A macro is a shorthand that replaces the five fields, such as @hourly, @daily, @weekly, @monthly and @yearly, plus @reboot which runs once when cron starts after a boot rather than on a clock schedule. - Day-of-month / day-of-week OR rule: When both the day-of-month and day-of-week fields are restricted (neither is a star), cron runs the job when either matches, not both. So 0 0 13 * 5 runs on the 13th and on every Friday. - Server timezone: Cron fires on the server's local timezone unless configured otherwise, not UTC or your laptop's time. A schedule set for 02:00 runs at 02:00 in whatever zone the machine is set to. FAQ: Q: What do the five fields in a cron expression mean? A: In order they are minute (0-59), hour (0-23), day of month (1-31), month (1-12) and day of week (0-6, Sunday is 0). A star in a field means 'every', so 0 2 * * * runs at 02:00 every day. Q: How do I run a cron job every 5 minutes? A: Use */5 in the minute field and stars elsewhere: */5 * * * *. The slash sets a step, so this fires at minute 0, 5, 10 and so on, every hour of every day. Q: How do I run a cron job every 15 minutes or every hour? A: Every 15 minutes is */15 * * * *. Every hour is 0 * * * * (at minute 0 of each hour), or the macro @hourly. For every 6 hours use 0 */6 * * *. Q: What is the cron expression for a daily job at a set time? A: Put the minute and hour and leave the rest as stars. Daily at 2am is 0 2 * * *; daily at 09:30 is 30 9 * * *. You can also use @daily, which is 0 0 * * *, for midnight every day. Q: What do the *, comma, hyphen and slash mean? A: A star means every value; a comma is a list (0,30 = minutes 0 and 30); a hyphen is a range (mon-fri); and a slash is a step (*/10 = every 10th value). They can be combined, for example 0-30/10 means 0, 10, 20, 30. Q: Why does my job with both a day-of-month and a weekday run more often than expected? A: When both the day-of-month and day-of-week fields are set (neither is *), cron runs the job when EITHER matches, not both. So 0 0 13 * 5 runs on the 13th and on every Friday, not only on Friday the 13th. To require both, test one condition inside the command. Q: Which time zone does cron use? A: Cron runs in the server's local time zone, not UTC or your laptop's time. Check it with timedatectl and make sure the VM is set to the zone you expect, such as IST, before relying on the schedule. Q: What are cron macros like @daily and @reboot? A: Macros replace the five fields with a shorthand: @hourly, @daily, @weekly, @monthly and @yearly map to common schedules, while @reboot runs the job once when cron starts after a boot rather than on a clock schedule. --- ## Nginx config generator URL: https://servercake.in/tools/nginx-config-generator Free nginx config generator. Build a server block for a reverse proxy, SSL/TLS, a static site or PHP-FPM, then copy it. Runs in your browser, nothing sent to a Key facts: - Nginx serves each site from a server block whose listen and server_name directives decide which block handles a request. - A reverse proxy passes requests to an app with proxy_pass, and proxy_set_header lines are needed so the app sees the real client IP and scheme. - An HTTPS server block uses listen 443 ssl with ssl_certificate and ssl_certificate_key, and the fullchain file should include the leaf plus intermediate certificates. - A plain HTTP to HTTPS redirect is done with a listen 80 block that returns 301 https://$host$request_uri. - Nginx does not obtain TLS certificates itself; it only reads the certificate files you point it at, which are typically issued by Certbot or acme.sh. ### The anatomy of an nginx server block Nginx serves each site from a 'server' block inside the http context. The two directives that decide which block handles a request are 'listen' and 'server_name'. 'listen 80;' handles plain HTTP and 'listen 443 ssl;' handles HTTPS; 'server_name example.com www.example.com;' matches the Host header. A request that matches no server_name falls through to the default_server block. Inside the block you either serve files or hand the request off. 'root /var/www/example;' sets the directory that files are served from, and 'index index.html;' names the default file for a directory. To hand the request to another process instead you use 'proxy_pass' (for an app or upstream) or 'fastcgi_pass' (for PHP-FPM) inside a 'location' block - root and proxy_pass are mutually exclusive per location. 'location' blocks route by URI path or regex. 'location / { ... }' is the catch-all; 'location /api/ { ... }' matches a prefix; 'location ~ \.php$ { ... }' matches a regex. Nginx picks the most specific match, so a static-file location and a proxy location can coexist in one server block. ### Reverse proxy to an app on a port The most common setup is putting nginx in front of an app (Node, Django, Rails, a Go binary) that listens on a local port such as 127.0.0.1:3000. Nginx terminates the public connection and forwards the request to the app. A minimal proxy location looks like this: 'location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }'. The proxy_set_header lines matter: without them the app sees nginx's address instead of the real client, and cannot tell HTTP from HTTPS. For WebSockets, also add 'proxy_http_version 1.1;', 'proxy_set_header Upgrade $http_upgrade;' and 'proxy_set_header Connection "upgrade";'. Bind the app to 127.0.0.1, not 0.0.0.0, so only nginx can reach it. For several backends you can define an 'upstream' block with multiple 'server' lines and proxy_pass to it by name, which gives you basic load balancing across app instances. ### SSL/TLS and the HTTP to HTTPS redirect To serve HTTPS, the server block listens on 443 with the ssl flag and points to your certificate and key: 'listen 443 ssl;', 'ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;', 'ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;'. Use the fullchain file (leaf plus intermediates) so clients that do not cache intermediates still trust the chain. Send plain HTTP to HTTPS with a small dedicated block: 'server { listen 80; server_name example.com; return 301 https://$host$request_uri; }'. A 301 return is cheaper and cleaner than an if/rewrite. Restrict protocols to 'ssl_protocols TLSv1.2 TLSv1.3;' and let nginx pick a modern cipher set; the Mozilla SSL Configuration Generator is the standard source for a hardened block. Nginx does not obtain certificates - it only reads the files you point it at. Get a free certificate with Certbot or acme.sh (Let's Encrypt), then reference the issued paths. Certbot can also edit the config for you, but the generator here writes the directives so you can paste them in yourself. ### Static sites, PHP-FPM, gzip and where the file lives A static site needs only a root and a fallback: 'root /var/www/site;' plus 'location / { try_files $uri $uri/ =404; }' (single-page apps use 'try_files $uri $uri/ /index.html;' so client-side routes resolve). A PHP site adds a location that passes .php requests to PHP-FPM over a socket: 'location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }'. Turn on compression once, globally or per server, to cut transfer size: 'gzip on; gzip_types text/css application/javascript application/json image/svg+xml; gzip_min_length 1024;'. HTML is compressed by default, so it is not listed. There is no point gzipping already-compressed formats like JPEG or PNG. On Debian and Ubuntu the file goes in /etc/nginx/sites-available/ and is symlinked into /etc/nginx/sites-enabled/; on RHEL, CentOS and Alma it goes in /etc/nginx/conf.d/ with a .conf suffix. After copying it in, always validate before reloading (see the steps below). Glossary: - Server block: A server block is the nginx configuration unit that defines one virtual host inside the http context. Its listen and server_name directives decide which block handles an incoming request. - listen and server_name: The listen directive sets the port and flags, such as listen 80 for HTTP or listen 443 ssl for HTTPS, while server_name matches the request's Host header to select the block. - Location block: A location block routes requests by URI path or regex within a server block. Nginx picks the most specific match, so a static-file location and a proxy location can coexist in one server block. - Reverse proxy (proxy_pass): A reverse proxy forwards requests to a backend app with proxy_pass, for example proxy_pass http://127.0.0.1:3000. proxy_set_header lines are needed so the app sees the real client IP and scheme. - root vs proxy_pass: root serves files directly from a directory on disk for static content, while proxy_pass hands the request to another process and returns its response. They are mutually exclusive within a single location. - SSL directives: An HTTPS server block uses listen 443 ssl with ssl_certificate and ssl_certificate_key pointing at the certificate files. The fullchain file should include the leaf plus intermediate certificates. FAQ: Q: How do I set up nginx as a reverse proxy? A: Put a proxy_pass in the location block that points at your app's local address, for example 'location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }'. Bind the app to 127.0.0.1 so only nginx can reach it, then run 'nginx -t' and reload. Q: What is the difference between root and proxy_pass? A: 'root' tells nginx to serve files straight from a directory on disk - use it for static sites and assets. 'proxy_pass' hands the request to another process, such as an app on a port or an upstream, and returns its response. They are mutually exclusive within one location: a location either serves files or proxies, not both. Q: How do I add SSL and force HTTPS in nginx? A: In the HTTPS block use 'listen 443 ssl;' with 'ssl_certificate' pointing at your fullchain.pem and 'ssl_certificate_key' at your privkey.pem. Then add a separate port 80 block that redirects: 'server { listen 80; server_name example.com; return 301 https://$host$request_uri; }'. Nginx reads the certificate files but does not issue them - get one from Let's Encrypt with Certbot or acme.sh. Q: How do I configure PHP with nginx? A: Nginx does not run PHP itself; it passes .php requests to PHP-FPM. Add 'location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }' and set the server's 'root' to your web directory. Confirm the FPM socket path matches your installed PHP version. Q: What does 'nginx -t' do and how do I apply a config? A: 'nginx -t' parses your configuration and checks the syntax and referenced file paths without touching the running server; it prints 'test is successful' when the config is valid. Only after that, apply the change with 'systemctl reload nginx' or 'nginx -s reload', which reloads gracefully without dropping live connections. Never reload before the test passes. Q: Where do I put the nginx config file? A: On Debian and Ubuntu, save it in /etc/nginx/sites-available/ and symlink it into /etc/nginx/sites-enabled/. On RHEL, CentOS and Alma, place a .conf file in /etc/nginx/conf.d/. Both are pulled in by the main /etc/nginx/nginx.conf via an include, so the server block loads on the next test and reload. Q: How do I turn on gzip compression? A: Add 'gzip on;' and list the types to compress, for example 'gzip_types text/css application/javascript application/json image/svg+xml;', plus 'gzip_min_length 1024;' to skip tiny responses. HTML is compressed by default so it need not be listed. Do not gzip already-compressed formats like JPEG, PNG or WebP - it wastes CPU for no gain. Q: Is anything I enter in the generator sent to a server? A: No. The config is built entirely in your browser, so the domain names, ports and upstream addresses you type stay on your machine. You copy the finished server block and paste it onto your own server. --- ## Guides (hands-on, every command tested on a live Ubuntu server) Hub: https://servercake.in/guides - The Linux Command Line: A Hands-On Guide https://servercake.in/guides/the-linux-command-line A nine-part, hands-on introduction to the Linux command line and filesystem, from your first login to writing dotfiles. Every command run on a live Ubuntu server so you see the real output, not a mock-up. - Users and Permissions on Linux: A Hands-On Guide https://servercake.in/guides/users-and-permissions A nine-part, hands-on guide to Linux users, groups and file permissions: ownership, chmod, sudo, SSH keys, umask, ACLs and password policy. Every command run on a live Ubuntu server against a real service account. - Processes and Services on Linux: A Hands-On Guide https://servercake.in/guides/processes-and-services A nine-part, hands-on guide to what runs on a Linux server: processes and signals, background jobs, systemd services and journald, enabling and masking units, cron, systemd timers, and resource limits. Every command run on a live Ubuntu server. - Package Management on Ubuntu: A Hands-On Guide https://servercake.in/guides/package-management A nine-part, hands-on guide to installing and managing software on Ubuntu: apt, searching and inspecting packages, repositories and GPG keys, dpkg, pinning versions, PPAs, building from source, snap, and keeping a server patched. Every command run on a live Ubuntu server. - Linux Networking from the Terminal: A Hands-On Guide https://servercake.in/guides/linux-networking-basics A nine-part, hands-on guide to networking from the Linux command line: interfaces and ip, ports and ss, DNS, curl, scp and rsync, ufw, ping and traceroute, SSH tunnels, and diagnosing a slow connection. Every command run on a live Ubuntu server. - Storage, Text and Your First Scripts: A Hands-On Guide https://servercake.in/guides/storage-and-scripting A nine-part, hands-on guide to disks and filesystems, tar, the text tools sed, awk, cut, sort and uniq, and writing your first bash script and scheduled backup. Every command run on a live Ubuntu server. - Linux Server Hardening: A Hands-On Guide https://servercake.in/guides/linux-server-hardening A six-part, hands-on guide to securing a Linux server end to end, from the first hour on a new VPS to responding to a breach. Every command tested on a live server. - systemd Deep Dive: A Hands-On Guide https://servercake.in/guides/systemd-deep-dive A seven-part, hands-on guide to systemd on a single VPS: the unit model and how boot resolves, writing services that recover from a crash, journald and journalctl, timers versus cron, sandboxing and security scoring, cgroups v2 resource control, and socket activation with user services. Every command tested on a live Ubuntu 24.04 server. - SSH Mastery: A Hands-On Guide https://servercake.in/guides/ssh-mastery A six-part, hands-on guide to SSH on a single VPS: key authentication over passwords, the config file with jump hosts and multiplexing, hardening sshd without locking yourself out, local, remote and dynamic port forwarding, agent forwarding and its hijack risk, and file transfer with host-key verification. Every command tested on a live Ubuntu 24.04 server. - Firewalls with nftables: A Hands-On Guide https://servercake.in/guides/firewalls-with-nftables A five-part, hands-on guide to building a firewall with nftables on a single VPS: the family, table and chain model that replaced iptables, a safe policy-drop base ruleset that keeps your SSH session alive, sets, maps and rate limiting, NAT with port forwarding and logging, and persistence with a dry-run and a dead-man revert. Every command tested on a live Ubuntu 24.04 server. - DNS on a Server: A Hands-On Guide https://servercake.in/guides/dns-on-a-server A five-part, hands-on guide to running DNS on a single VPS: how resolution walks from root to authoritative, an authoritative BIND9 server with a real zone file, a validating caching resolver with unbound, split-horizon views for internal names, and DNSSEC with troubleshooting. Every command tested on a live Ubuntu 24.04 server with the demo servers bound to loopback. - WireGuard VPN and Private Networking: A Hands-On Guide https://servercake.in/guides/wireguard-vpn-and-private-networking A five-part, hands-on guide to running your own WireGuard VPN on a slice: install and configure the server from a bare box, connect your real laptop and phone, reach a private service through the tunnel that the public internet cannot see, and keep it running. Every command verified on a live Ubuntu 24.04 server with a real client connecting over the internet. - Secrets Management on a VPS: A Hands-On Guide https://servercake.in/guides/secrets-management-on-a-vps A four-part, hands-on guide to handling secrets on a single VPS: how plaintext secrets leak through permissions, the process environment, logs and git history, file-based secrets with a dedicated owner and systemd credentials, encryption at rest with age and sops, and rotation, auditing and git-history scrubbing. Every command tested on a live Ubuntu 24.04 server with throwaway demo secrets. - PostgreSQL for Production: A Hands-On Guide https://servercake.in/guides/postgresql-for-production A four-part, hands-on guide to running PostgreSQL in production on a single VPS: least-privilege roles, backups that actually restore, connection pooling, and tuning. Every command tested on a live 2-vCPU server. - MySQL / MariaDB for Production: A Hands-On Guide https://servercake.in/guides/mysql-for-production An eight-part, hands-on guide to running MariaDB in production on a single VPS: install and secure, least-privilege users, InnoDB indexing, backups that restore, primary to replica replication, ProxySQL connection pooling, slow-query monitoring, and security hardening. Every command tested on a live Ubuntu 24.04 server. - PostgreSQL Replication and HA: A Hands-On Guide https://servercake.in/guides/postgresql-replication-and-ha A five-part, hands-on guide to PostgreSQL high availability on a single VPS: streaming replication, synchronous replication and slots, failover and promotion with pg_rewind, connection routing with PgBouncer, and point-in-time recovery. Every command tested on a live Ubuntu 24.04 server running two clusters. - Redis: Caching, Sessions and Queues: A Hands-On Guide https://servercake.in/guides/redis-caching-sessions-queues A six-part, hands-on guide to running Redis on a single VPS: the five core data types, cache-aside with TTL and eviction, RDB and AOF persistence, a session store and rate limiter, pub/sub and queues with Streams, and security hardening. Every command tested on a live Ubuntu 24.04 server. - Nginx in Production: A Hands-On Guide https://servercake.in/guides/nginx-in-production An eight-part, hands-on guide taking Nginx from a fresh install to a hardened, fast production reverse proxy: the config model, server blocks, reverse proxy, HTTP/2 and HTTP/3, caching, rate limiting, load balancing, and hardening. Every command tested on a live server. TLS certificates get their own dedicated series. - Node.js in Production: A Hands-On Guide https://servercake.in/guides/nodejs-in-production A six-part, hands-on guide to running Node.js in production on a single VPS: install the LTS and serve behind nginx, run it under systemd, configure it with environment secrets, cluster across cores, deploy with zero downtime, and add health checks and metrics. Every command tested on a live Ubuntu 24.04 server. - Python Web Apps in Production: A Hands-On Guide https://servercake.in/guides/python-web-apps-in-production A six-part, hands-on guide to running a Python web app in production on a single VPS: a virtualenv and Flask under gunicorn, a systemd service, nginx over a unix socket, environment secrets, worker sizing, and zero-downtime reloads with health checks. Every command tested on a live Ubuntu 24.04 server. - PHP-FPM and the LEMP Runtime: A Hands-On Guide https://servercake.in/guides/php-fpm-and-lemp A five-part, hands-on guide to running PHP in a LEMP stack on a single VPS: install php-fpm and serve through nginx, size a dedicated fpm pool, put a real app behind nginx with a safe FastCGI config, tune OPcache, and harden the runtime. Every command tested on a live Ubuntu 24.04 server. - Caddy: the Auto-HTTPS Web Server, A Hands-On Guide https://servercake.in/guides/caddy-auto-https-web-server A five-part, hands-on guide to running Caddy on a single slice: install it from the official repo and read the Caddyfile, serve a static site with automatic HTTPS, reverse proxy an app with load balancing and websockets, serve PHP over FastCGI, and harden it for production. Every command verified on a live Ubuntu 24.04 server. - TLS and Certificates: A Hands-On Guide https://servercake.in/guides/tls-and-certificates A five-part, hands-on guide to TLS and certificates on a live server: reading the handshake and certificate chain, issuing Let's Encrypt and wildcard certificates, automating renewal with certbot, enforcing client certificates with mTLS, and debugging TLS with openssl and testssl.sh. Every command tested on a live Ubuntu 24.04 server. - Deploying an App on a VPS: A Hands-On Guide https://servercake.in/guides/deploying-an-app-on-a-vps A four-part, hands-on guide to getting an app onto a server the right way: behind nginx, running under systemd, served over HTTPS, and deployed with zero downtime. Every command tested on a live server. - CI/CD on a Single VM: A Hands-On Guide https://servercake.in/guides/cicd-on-a-single-vm A five-part, hands-on guide to real CI/CD on one VPS: push-to-deploy with a git hook, a self-hosted webhook runner, a build to test to deploy pipeline where a red test blocks the release, secrets kept out of the repo and the logs, and a health-gated zero-downtime release with one-command rollback. Every command tested on a live Ubuntu 24.04 server. - Docker & Compose on a VPS: A Hands-On Guide https://servercake.in/guides/docker-and-compose-on-a-vps A four-part, hands-on guide to Docker without the cargo-culting: your first container, building your app's image, a real app-plus-database stack with Compose, and running it safely in production. Every command tested on a live server. - Docker in Production: A Hands-On Guide https://servercake.in/guides/docker-in-production A seven-part, hands-on guide to running Docker in production on a single VPS: your first container and the image model, a Dockerfile and a multi-stage build, a Compose stack with a datastore, volumes and networks, resource limits and restart policies, logging and observability, and security hardening. Every command tested on a live Ubuntu 24.04 server. - Podman and Rootless Containers: A Hands-On Guide https://servercake.in/guides/podman-rootless-containers A four-part, hands-on guide to running containers rootless with Podman on a single slice: install and run your first daemonless container as an ordinary user, the user namespace and networking that make it safe, an app-and-datastore pod that talks over localhost, and Quadlet units that run it under systemd. Every command verified on a live Ubuntu 24.04 server. - k3s: Kubernetes on One VM https://servercake.in/guides/k3s-kubernetes-on-one-vm A seven-part, hands-on guide to running Kubernetes on a single VPS with k3s: install and your first pod, Deployments and self-healing, Services and networking, Ingress, ConfigMaps and Secrets, persistent storage with limits and probes, and day-two operations with backup and upgrades. Every command tested on a live Ubuntu 24.04 server. - Object Storage with MinIO: A Hands-On Guide https://servercake.in/guides/object-storage-with-minio A four-part, hands-on guide to self-hosting S3-compatible object storage with MinIO: run it as a service, work with buckets and objects, use the S3 API and presigned URLs from your app, and turn on versioning and lifecycle rules. Every command tested on a live server. - Backups & Disaster Recovery: A Hands-On Guide https://servercake.in/guides/backups-and-disaster-recovery A four-part, hands-on guide to backups that actually restore: an encrypted deduplicated restic repository in object storage, snapshots and cheap history, the restore test that most teams skip, and retention plus a nightly systemd timer. Every command tested on a live server. - Metrics & Monitoring with Prometheus: A Hands-On Guide https://servercake.in/guides/metrics-and-monitoring-with-prometheus A four-part, hands-on guide to seeing inside your server: node_exporter metrics, Prometheus collecting and storing them, PromQL to ask real questions, and alert rules that page you before users notice. Every command tested on a live server. - Logging and Log Management: A Hands-On Guide https://servercake.in/guides/logging-and-log-management A five-part, hands-on guide to logging on a single VPS: how journald and rsyslog fit together and where logs live, structured JSON logs with jq and logrotate, shipping logs to a central rsyslog collector over TCP, querying with journalctl and jq plus a threshold alert, and a retention, masking and compliance policy. Every command tested on a live Ubuntu 24.04 server. - Linux Performance and Troubleshooting: A Hands-On Guide https://servercake.in/guides/linux-performance-and-troubleshooting A seven-part, hands-on guide to finding why a Linux server is slow: the USE method with top and vmstat, CPU saturation with mpstat and pidstat, memory and the OOM killer, disk IO with iostat and iotop, network throughput with ss and tcpdump, a sixty-second triage playbook, and inodes, lsof and file limits. Every command tested on a live Ubuntu 24.04 server. --- ## Tutorials (hands-on, every step verified on a real server) Hub: https://servercake.in/tutorials - How to Install WordPress on a VPS https://servercake.in/tutorials/install-wordpress-on-a-vps Install WordPress on a VPS from scratch on Ubuntu 24.04: the LEMP stack, a least-privilege database, your domain over real HTTPS, and a hardened site. - How to Migrate WordPress to a VPS https://servercake.in/tutorials/migrate-wordpress-to-a-vps Migrate WordPress to a VPS the safe way: export your files and database, move them to a slice, fix the URLs, and cut over from shared hosting with no downtime. - How to Speed Up WordPress on a VPS https://servercake.in/tutorials/speed-up-wordpress-on-a-vps Speed up WordPress on a VPS with a tuned OPcache, a Redis object cache and an nginx FastCGI micro-cache, proven with a real before and after load test. - How to Secure WordPress on a VPS https://servercake.in/tutorials/secure-wordpress-on-a-vps Secure WordPress on a VPS and prove every control: locked file permissions, a blocked XML-RPC, a real fail2ban ban, two-factor auth and live security headers. - How to Back Up WordPress on a VPS https://servercake.in/tutorials/backup-wordpress-on-a-vps Back up WordPress on a VPS: dump the database and files to one archive, push it offsite to object storage, and prove it with a real restore drill. - How to Install WooCommerce on a VPS https://servercake.in/tutorials/install-woocommerce-on-a-vps Install WooCommerce on a VPS on top of your WordPress stack: set up the store in INR, add products with images, and place a real Cash on delivery test order. - How to Install Nextcloud on a VPS https://servercake.in/tutorials/install-nextcloud-on-a-vps Install Nextcloud on a VPS from a bare Ubuntu 24.04 slice: the stack, a verified download, real HTTPS, first login, and every recommended setting fixed and green. - How to Speed Up Nextcloud on a VPS https://servercake.in/tutorials/speed-up-nextcloud-on-a-vps Speed up Nextcloud on a VPS with APCu and Redis caching, transactional file locking, PHP and OPcache tuning, a system cron and HTTP/2, measured before and after. - How to Back Up Nextcloud on a VPS https://servercake.in/tutorials/back-up-nextcloud-on-a-vps Back up Nextcloud on a VPS: quiesce with maintenance mode, dump the database, archive the config and data, push it offsite, and prove it with a real restore drill. - How to Self-Host n8n on a VPS https://servercake.in/tutorials/self-host-n8n-on-a-vps Self-host n8n on a VPS with Docker Compose and Postgres: from a bare Ubuntu 24.04 slice to your own automation platform over real HTTPS, with a workflow that runs. - How to Run n8n in Production https://servercake.in/tutorials/run-n8n-in-production Take a single-container n8n to a production setup: queue mode with Redis, a dedicated worker pool, real secrets, and a stack that survives a restart. - How to Secure n8n on a VPS https://servercake.in/tutorials/secure-n8n-on-a-vps Secure n8n on a VPS end to end: put the API behind a login, encrypt stored credentials, lock it to localhost behind TLS, and sign your webhooks. - How to Self-Host Immich on a VPS https://servercake.in/tutorials/self-host-immich-on-a-vps Self-host Immich on a VPS with Docker Compose: from a bare Ubuntu 24.04 slice to your own photo timeline over real HTTPS, with real photos uploaded. - How to Back Up Immich on a VPS https://servercake.in/tutorials/back-up-immich-on-a-vps Back up Immich on a VPS: quiesce the server, dump the database Immich's way, archive the upload library, push it offsite, and prove it with a real restore drill. - How to Install Ghost on a VPS https://servercake.in/tutorials/install-ghost-on-a-vps Install Ghost on a VPS the clean way: ghost-cli with MySQL 8 and nginx over real HTTPS, then create the admin and publish a first post from the Ghost editor. - How to Back Up and Migrate Ghost on a VPS https://servercake.in/tutorials/back-up-and-migrate-ghost Back up and migrate Ghost on a VPS: dump the database, archive the content and config, push it offsite, and prove it by moving to a fresh slice and restoring. - How to Install Gitea on a VPS https://servercake.in/tutorials/install-gitea-on-a-vps Install Gitea on a VPS the clean way: a verified Gitea binary with MySQL 8 and nginx over real HTTPS, then create a repository and push your first commit. - How to Install Coolify on a VPS https://servercake.in/tutorials/install-coolify-on-a-vps Install Coolify on a VPS the right way: the one-command install, the first admin login, and a first app deployed and running, all on a box you own. --- ## Contact - Website: https://servercake.in - Email: support@servercake.in