How to force dynamically allocated classes to have their members allocate on the heap as well?

Currently working on cross-platform allocation, where I am given a system, which has a very limited "stack" as an automatic scope for variables. However, said stack is still commonly used and filling up quickly. I was not allowed to increase the size, so I have to solve this programmatically.

---

Firstly, I have searched for similar questions, the most relevant being this one. However, there someone states that a member of a dynamically allocated class, will be allocated on the "heap", but those are apparently merely implementation details (So it might differ? Very confusing).

For simplicity, I am using a Linear Allocator, which allocates memory using a call to malloc and then offsets the pointer depending on the size of the class. Then creating/allocating the class, would be done with:

template<typename T> T* CreatePtr(size_t align)
{
    void *adr= Allocate(sizeof(T), align);

    return new(Adress) T();
}

So a class, which would be created using the above method, could be:

class A
{
    uint64_t size = 0u;
    bool foo = false;
    void *ptr = nullptr;
}

As I understand it, member size is allocated on the "heap", since class A was allocated using the LinearAllocated, which uses a malloc call, thus allocating the class on the "heap" implementation, which is decently large on my platform.

---

Now back to the question: is this the behavior above the correct one for Windows, Linux et cetera, meaning the variables are using the memory offset, since I pass the size with sizeof(T) to make sure it can hold its members (right?).

How would that work if you have a STL container, such as a vector. Would it allocate the vector on the "stack" implementation, since sizeof(T) cannot possibly know how big a dynamic container could be, even if you reserve space.

I dearly appreciate any suggestions, I hope I can clear this up. The title would hint towards the XY-problem, but I wrote it the way it is to stress the need to save memory.